Native support for deployment pinning / skew protection

[emiliosheinz]

What I'm trying to do

We deploy a Vite SPA to Vercel many times a day. Each deployment re-hashes asset filenames, which means a tab left open on an older deployment can start returning 404s as soon as it lazy-loads a chunk.

The standard solution is skew protection: every asset request from a given build is tagged with that build’s deployment ID, for example ?dpl=<id>. This keeps an older tab pinned to its original asset graph, allowing it to continue loading immutable files from the deployment it was built against.

Vercel already serves these pinned assets. Next.js supports this out of the box through deploymentId

This isn’t specific to Next.js, either. SvelteKit supports asset pinning natively through its Vercel adapter, and Astro 5.15 added a first-class assetQueryParams hook for appending a per-deployment token to emitted asset URLs.

Vite is the remaining piece without first-class support.

What it takes today

experimental.renderBuiltUrl gets you part way. It rewrites new URL(...)-style asset references and public assets, so I can pin .js/image/font URLs there:

experimental: {
  renderBuiltUrl(filename, { type }) {
    if (type !== 'asset') return undefined
    return `${base}${filename}?dpl=${deploymentId}`
  }
}

But renderBuiltUrl does not touch the static or dynamic import specifiers that connect emitted chunks. Those are precisely the requests that 404 across deployments, and therefore, the URLs skew protection needs to pin.

To cover them today, I have to post-process the bundle myself:

• Run a generateBundle pass over every JavaScript chunk, use es-module-lexer to locate relative import/export specifiers, and append ?dpl= using magic-string.
• Run that pass with order: 'post', after Vite’s own import-analysis generateBundle step. If the URLs are rewritten earlier, Vite can no longer resolve the chunk dependencies correctly and silently drops them from the modulepreload list.
• Because this modifies already-emitted JavaScript, the existing sourcemap becomes invalid. I then have to recompose the maps by chaining MagicString’s edited → chunk map with Vite’s chunk → source map to produce a correct edited → source map, while preserving inlined source content. This requires @jridgewell/gen-mapping and @jridgewell/trace-mapping.
• build.sourcemap: 'inline' cannot be supported with this approach. By generateBundle, I can only rewrite an external .map asset, so the plugin has to hard-error when inline sourcemaps are enabled.

So what sounds like “append a query string to asset URLs” actually requires a WASM lexer, source rewriting, sourcemap recomposition, and a specific plugin-ordering constraint. Purely to modify URLs that Vite already emits and controls.

The ask

Would the team consider adding native support for deployment pinning?

For example, Vite could expose a built-in option such as build.deploymentId or versionQuery that appends a caller-supplied token to every emitted asset URL, including inter-chunk imports:

• JavaScript and CSS assets
• Dynamic imports
• modulepreload links

Ideally, this would happen inside Vite’s URL-emission pipeline, where things like sourcemaps and .css detection are already handled correctly.

This would be similar in shape to Next.js’s deploymentId or Astro’s assetQueryParams.

Alternatively, perhaps this could be supported through a first-party vercelSkewProtection-style plugin.

Happy to share the full plugin implementation, including the sourcemap-composition code, if that would be useful.