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 app/assets/stylesheets and app/javascript directories) and compile them down accordingly in the app/assets/builds dir.
They do that through their own separate processes, which you define in package.json, and make sure they run through a Procfile.
Then, Sprockets is responsible for only finding them in the app/builds directory and making them available to your app through javascript_include_tag and stylesheet_link_tag.
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.
https://github.com/avo-hq/avo/blob/main/package.json#L10-L16
Article derived from this tweet.
