# New Rails asset compilation mental model

I was doing a pairing session with [@lucianghinda](https://twitter.com/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](https://twitter.com/adrianthedev/status/1578306975238328320).