Keep assets from previous deployments available (e.g. code-splitting)

[dimaip]

I'm deploying a PWA with code splitting.
When the user already has the app open, and then the new deployment happens, and then tries to navigate to a route that requires an additional JS chunk, then the app would crash.
Is there a way to somehow make previously deployed versioned assets remain available after the new release (at least for some time), e.g. main.v1.js, main.v2.js etc.?
If not, how do you guys deploy web apps with code splitting?

AWS Amplify Console does it out of the box: all versioned assets from my previous deployments remain available (at least for some time, don't know for how long).

[coetry]

Hi @dimaip our CDN doesn't behave like that and we purge the cache for your projects with each new deployment and this is typically what most users want at the end of the day.

What you can do is have your service worker handle fetching assets and if a 404 is encountered due to a missing asset, you can update the service worker with the new assets.

Here's an article that might be of help to you: https://deanhume.com/displaying-a-new-version-available-progressive-web-app/

[dimaip]

Hey @coetry, thanks for your reply!

I know how to update a service worker, that's not what the question was about :)

Having the app to force-update after every deploy could work for some cases, but would be a very bad UX for stateful apps that contain user input.

I could of course pre-fetch all app assets at initial load, but that defeats the purpose of code splitting and consumes bandwidth, which is no-go for some mobile apps.

So there's just no way around it: for most apps that do code-splitting, the only reliable way to deploy is to keep previously deployed assets available.

what most users want at the end of the day

That might be the current situation because of the lack of awareness on the issue, I believe more and more people will see the ability to keep the previous chunks available to be a critical requirement for code-split apps. I've asked around, and all of my friends who deploy serious web apps, do keep old assets on CDNs.

So I would encourage you to think about implementing this behaviour (or at least making it optional), I believe it's right in the heart of your niche (deploying JAM stack)!

P.S. I've created a SO question to gather best practices on this topic, will turn it into an answer once I'm sure I've researched everything there is to it on the topic: https://stackoverflow.com/questions/61382892/how-to-deploy-js-app-that-has-code-splitting-making-sure-past-app-versions-don

[dimaip]

I've turned my discoveries into an article: http://dimaip.github.io/2020/04/25/deploying-apps-with-code-splitting/

[fredefl]

For over a year I've been looking to do code splitting with Vercel, however given that this issue still remains, it's impossible for is to go that route. From a UX perspective we wouldn't want our users bothered with notifications of new app versions, as our app is stateful and performing the needed refresh would result in users losing their form edits or their progress in a video (being a video platform).

From our point of view, the only reasonable solution would be to have the option of retaining older deployment versions. I don't know if there's an optimal retention period where you'd be certain that users would've migrated over on their own, but at least having a few hours of old asset retention on the CDN would be ideal.

Is it something you've discussed further internally? @coetry

[cabello]

I have the same issue, my app has video over WebRTC and asking someone on a call to refresh to load the latest application because the chunks are now missing from the CDN would be very disruptive.

I would prefer to have a setting, for example:

• keep the last of deployments in the CDN

[geirmarius]

An official answer to this from the Vercel team anno 2022 would be great. It's forcing us to only do nightly deploys (we don't have an international audience) unless we want to bother users with update popups and potentially losing state.

[amyegan]

I brought this up with our Engineering team and we have it on our internal list of requested features. Thank you all for sharing your blockers, workarounds, and ideas surrounding this feature request. This kind of information is very helpful as we plan new features!

[levaleks]

Hi. Do you have any ETA for it?

[cabello]

Why I can no longer find this discussion?

…

On Mon, Aug 29, 2022 at 1:56 PM Amy ***@***.***> wrote: I brought this up with our Engineering team and we have it on our internal list of requested features. Thank you all for sharing your blockers, workarounds, and ideas surrounding this feature request. This kind of information is very helpful as we plan new features! — Reply to this email directly, view it on GitHub <https://github.com/orgs/vercel/discussions/4140#discussioncomment-3502679>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAO4CCTTYELOFPLXB3TOD3V3T2THANCNFSM4MPQZ4WA> . You are receiving this because you commented.Message ID: ***@***.***>

[amyegan]

Hi @cabello! There are some problems happening with GitHub Discussions notifications rolling up to org level. I just moved this conversation so notification links should work going forward. Sorry for the inconvenience! The new address is #812

[acasademont]

We're also very interested in this, having the old assets removed on every deploy is a PITA, it would be great if we could keep them for a few hours at least

[Joroze]

My team would also benefit from this.

[silveur]

I am also having some many failed chunk loads because of this.
@amyegan do we have news for this feature?

A lot of sizable React apps requires code splitting and not being able to load chunks between deployments is really inconvenient.
It creates a lot of user misery and bug reports...

[NiklasPor]

I can only second this. I do not know of any B2B SPAs where we didn't use code splitting. 👍

[mark-meadows]

This is a major problem for us as well, we use Odoo with keycdn and the only solution we found for a quick fix was to use cloudflare always on. It seems to provide this functionality, but I'd much have a solution with keycdn that delays stale file cleanup...

[leerob]

Good news, this is something that is now available in Next.js behind a feature flag and is fully supported on Vercel.

We're calling this Skew Protection: https://vercel.com/blog/version-skew-protection

[umutuzgur]

We got a response from vercel support. You can reach the assets of a previous deployment, deployment skew, by adding the dpl={DEPLOYMENT_ID} query param. You can get the id during the vercel build phase via the env var VERCEL_DEPLOYMENT_ID. We are also using vue with vite and vite support for adding query params to the assets was painful

[chriz-hoepfner]

We got a response from vercel support. You can reach the assets of a previous deployment, deployment skew, by adding the dpl={DEPLOYMENT_ID} query param. You can get the id during the vercel build phase via the env var VERCEL_DEPLOYMENT_ID. We are also using vue with vite and vite support for adding query params to the assets was painful

@umutuzgur Good to know that, next to requests headers, query params are also an option. Did you find a way to add the query param for Vite asset requests?

[umutuzgur]

In a really hacky way but it didn't work for the css files. We changed the file output format during the build and dropped it from the filename afterwards. CSS files have some special handling in the vite plugins so they didn't like our hack with the files names

 build: {
      target: 'esnext',
      rollupOptions: {
        output: {
          // https://vercel.com/blog/version-skew-protection
          chunkFileNames: `assets/[name]-[hash].js${process.env.VERCEL_DEPLOYMENT_ID ? `?dpl=${process.env.VERCEL_DEPLOYMENT_ID}` : ''}`,
          entryFileNames: `assets/[name]-[hash].js${process.env.VERCEL_DEPLOYMENT_ID ? `?dpl=${process.env.VERCEL_DEPLOYMENT_ID}` : ''}`,

This is the command we run to sanitize the filenames afterwards

    "clear-vercel-filename-hash": "[ -n \"$VERCEL_DEPLOYMENT_ID\" ] && for f in dist/assets/*?dpl=$VERCEL_DEPLOYMENT_ID*; do newname=\"${f//?dpl=$VERCEL_DEPLOYMENT_ID/}\"; mv \"$f\" \"${f//?dpl=$VERCEL_DEPLOYMENT_ID/}\"; done"

[priithansen]

There is also a experimental renderBuiltUrl api for Vite that seems to take care of asset url-s and entry points but sadly doesn't seem to affect chunk urls.

https://vitejs.dev/guide/build.html#advanced-base-options

export default defineConfig({
  ...
  experimental: {
    renderBuiltUrl(filename) {
      return `${filename}?dpl=${process.env.VERCEL_DEPLOYMENT_ID}`
    },
  },
})

vitejs/vite#13996
vitejs/vite#13834 (reply in thread)

[umutuzgur]

Oh nice, thanks for pointing out the issue. I hope they tackle it so we can get rid of our own hack