Cleanup pre-digested versions

[schmijos]

This makes Propshaft responsible for -[digest].digested files in the output path. Propshaft copies them from the load path into the output path. So it should also clean them up (addressing #140).

I refrained from making -[digest].digested files into a Propshaft::Asset, because this proposal has less moving parts and @dhh doesn't want to invest in non-container setups were cleanup is needed at all.

[brenogazzola]

I'm reading the code but I don't see anything that let's it handle the problem with esbuild where all chunks have the same name.

For example, I have an empty public/assets folder, and after running assets:precompile I get this:

application-d70br74r.js
chunk-4hs4lcvp.digested.js
chunk-iz6s2ho9.digested.js
chunk-ftjr8syz.digested.js

All the chunks above are fresh and required. Then after some changes in my JS file I run assets:precompile again and get this:

application-d70br74r.js
chunk-4hs4lcvp.digested.js
chunk-iz6s2ho9.digested.js
chunk-ftjr8syz.digested.js
chunk-tc9xpclk.digested.js
chunk-cy696x68.digested.ks

Now, which are two stale chunks?

[schmijos]

Ok, I see: there is no logical name (at least not without hash). Predigested files map 1-on-1 in the manifest. So we should not assume anything (the hash could even be the logical name in edge cases).

An idea to resolve this:

1. The version cannot be derived from the name but we can still cleanup predigested outputs by age (1.hour per default).
2. Because this could lead to a race condition where the previous version is still accessed but already gone (that's why count is 2 by default, I guess), we would group predigested outputs by :mtime ranges.

Does this sound sane? It would mean to implement a proper case distinction between Propshaft-digested output assets and predigested ones in Propshaft::OutputPath.

[brenogazzola]

I just did a quick check, and if I run rails assets:precompile, esbuild does not update the timestamp of files it generates. So I don't think your one hour limit would work.

1 - Deploy at 3 AM, 5 chunks files with identical names and different hashes are generated
2 - Deploy at 5 AM, no change in the chunks, but they are now 2 hours out.
3 - The 1 hour limit means all of them are considered too old (except maybe 2) and will be removed.

[schmijos]

Ok. I think this to be a dead end. Thank you for your review. I learned some things.

[brenogazzola]

No problem. Thank you for making the attempt. Having to support multiple bundlers does make things complicated when they don’t agree on how to do things.