Scripts in my app are in chunks, some are being loaded immediately, some shortly after everything else was loaded and the others based on user actions. I have a problem where users are requesting files that no longer exists because they loaded an app with version X and then there was a deployment of the new one.
I use a build script that auto-generates file name so it looks like this: 3.eebedef8.chunk.js
In theory, I could make them look always the same but then I risk that a user would run code from two versions at the same time.
What you’re suggesting I don’t think is a direct solution to the problem I’m facing but it could change it.
If I keep the filenames on each deploy then people using my app will end up having scripts from two different versions running at the same time.
An example:
When user opens root page it pulls index.js and vendor.js (with all packages). Then once the user goes to /video page it dynamically requests video.js. If I deployed changes when a user was on root page that involved extra library then going to /video is going to crash because that library was never loaded.
So the strategy you’re suggesting makes sense only if every js chunk is fully independent.
What Dennis was attempting to suggest was that you will likely need to change your app architecture since indeed, we don’t keep a copy of the old stuff around - only what you have just built is pushed live. This is probably a more straightforward description of the problem and possible changes:
You could of course push the “old” files to cache at the end of the old build, and restore them during new build using something like cache-me-outside - npm - but then, how will you ever get your visitors updated to the new code if you allow them to use the old? Tis a problem you’ll have to solve somehow
