I was doing a pairing session with @lucianghinda trying to convert an older webpacker Rails app to esbuild & tailwind, and we noticed something.
The mental model of this transition wasn't adequately communicated when the new packages were first introduced.
Before, regular Sprockets asset handling (CSS & JS) or Webpacker worked closely together with your Rails app through Sprockets.
The app knew where to look for and compile the assets for you.
It was a part of its lifecycle.
Now, with the js-bundling and tailwindcss-rails gems, that process is decoupled from the application lifecycle.
They do their own thing: find the entry points (in
They do that through their own separate processes, which you define in
package.json, and make sure they run through a
Then, Sprockets is responsible for only finding them in the
app/builds directory and making them available to your app through
So when your Rails app boots up, it requests those compiled files from
app/builds, Sprockets (or Propshaft) gives it the files, then they are sent to the browser.
Of course, this is all from the default way of using these tools. You can go wild and configure them in multiple ways.
We use multiple strategies with Avo when deploying to production, and you can check them out on our repo.
Article derived from this tweet.