Register dependencies with Sprockets to enable cache invalidation

[sudhirj]

Fixes #7

The asset pipeline currently doesn't recompile the output CSS at all, because the source Tailwinds CSS file remains the same even if the templates that use the classnames change. This means that calling assets:precompile in production does nothing after the first time, even if templates have changed and new purging needs to happen.

This PR adds all files_with_class_names used as dependencies to the compiled asset, which re-complies the output CSS correctly.

[dhh]

Great. Can you find a way to add some tests to this?

[dhh]

What's the point of adding the note if we're fixing the underlying problem with this change?

[dhh]

I mean, in development, you don't have any need for purging. That's solely for production. So if this approach doesn't work for production, I don't think it works?

[sudhirj]

Will add tests.

There's still a problem, though. This will add all the files that we use to extract class names into the cache key, but it won't work for new files being created that reference class names. The processor will never get called at all, unless the existing files already in the cache key are modified by some coincidence.

The only way I can think of is to take in a new option, like a list of directories- which will usually just be ['app/views'] and add the whole directory as a key. Anyone who wants to add a new directory will have to do assets:clobber again, though. Doesn't seem that useful.

[dhh]

I think adding an entire directory as a dependency makes sense? As long as it picks up app/views/new_directory. Otherwise, yes, agree, we might just document that you do need to do assets:clobber.

[sudhirj]

Will add the directory option, make it an array, default it to ['app/views']. Ideally there should be a way to read that off the existing option as well, like a deepest-common-ancestor problem. Will just do that instead I can figure out how.

Will update the docs to remind users to do a clobber if the directories or the glob list itself changes.

Should we also point out that this is a giant problem in Heroku? There isn't actually a way to fix my Heroku deployment now short of installing a special plugin and nuking the entire application build cache. I wound up building assets locally and checking them into VCS.

[dhh]

We need app/helpers as well. And next step think about how we deal with engines. We preferably need to include all Action Pack view load paths in this.

Heroku won't let you run assets:clobber?

[sudhirj]

The more I think about this the more it seems like the better way to do it would be to ask people to either run assets:clobber when deploying to production, or turn off the asset cache store for production with the instructions in the guide. I don't think any amount of magic can handle 100% of the cases, and this is a problem where sites will work in dev but break in production if devs forget to clobber, which is a horrible experience.

Heroku lets you run any command on a new instance started up for you, but the build machine that assets:precompile runs on is off-limits. It runs asset:precompile on the build machine, then copies the assets & slug to each dyno. Folks wind up running commands on the dynos assuming they're somehow modifying the build machine / all dynos, but that just leads to much headbanging.

[dhh]

So what's the answer for making this work better on Heroku? Seems like we need a proper solution here.

[sudhirj]

Anyone who deployed to Heroku must clear the build cache using the instructions in https://help.heroku.com/18PI5RSY/how-do-i-clear-the-build-cache before every deployment, unless they decide to compile locally and check in public/assets to version control.

When compile the assets locally everyone needs to run RAILS_ENV=production bin/rails assets:clobber assets:precompile every time.

I'm trying to figure out how to disable caching on the asset pipeline, will post once I have a working method. The null_store option doesn't seem to be working for me.

[sudhirj]

Closing this PR, I don't think #7 can be solved this way.

#7 (comment) details my current workaround and recommendations.