svelte.config.js version changes cause most client chunks to generate a new hash despite no other changes #12260

Activity

1. Conduitry commented on May 24, 2024

   

   Conduitry

   on May 24, 2024

   Member

   More actions

   You need to set https://kit.svelte.dev/docs/configuration#version to something consistent; otherwise, it uses the current timestamp, which changes every build, affecting the hashes.

   👍React with 👍1Reacted by Arthur Silva
2. rory-orennia commented on May 24, 2024

   

   rory-orennia

   on May 24, 2024

   Author

   More actions

   @Conduitry Ohh thank you! That was definitely it. I guess now my concern is, how is this supposed to work in the case of making a vendor.js file? Unless I hardcode the version to something and then ignore the svelte version handling, I'm still going to get a different vendor.js file every time I do a new commit (assuming you tie version to git like is suggested).
   I think even if I manually pulled this version check out into another chunk, it would be referenced by most other client chunks in the app and thus they would also change their hash.
3. rory-orennia commented on May 24, 2024

   

   rory-orennia

   on May 24, 2024

   Author

   More actions

   Here's me changing the svelte.config.js -> version -> name from 1 to 2 and it basically changing every client chunk
   
4. teemingc

   closed this as not plannedon May 25, 2024
5. teemingc

   reopened this on May 25, 2024
6. mquandalle commented on May 27, 2024

   

   mquandalle

   on May 27, 2024

   More actions

   If two compiled files across two distincts app versions are exactly the same, why not keep the same file name to avoid unnecessary cache invalidation on the client?
7. rory-orennia commented on May 27, 2024

   

   rory-orennia

   on May 27, 2024

   Author

   More actions

   If two compiled files across two distincts app versions are exactly the same, why not keep the same file name to avoid unnecessary cache invalidation on the client?

   That's the problem. They aren't exactly the same because some base level sveltekit code gets changed, and then most client code chunks import that change, which causes them to change because the hash they reference (eg. import somebasefile.constantlychanginghash.js) has changed.

   If the cause of all of this is the version check code, I think we need to find a way to make that code not bleed into every client chunk

   👍React with 👍4Reacted by Tee Ming, Maxime Quandalle, Axel and michael-haberzettel
8. rory-orennia commented on May 27, 2024

   

   rory-orennia

   on May 27, 2024

   Author

   More actions

   @eltigerchino @Conduitry Do you want me to close this ticket and open a new one that is the new problem? (Version changes cause most client chunks to generate a new hash despite no other changes). Or do you want me to rename this one instead?
9. teemingc commented on May 27, 2024

   

   teemingc

   on May 27, 2024

   Member

   More actions

   @eltigerchino @Conduitry Do you want me to close this ticket and open a new one that is the new problem? (Version changes cause most client chunks to generate a new hash despite no other changes). Or do you want me to rename this one instead?

   Yes, renaming this one would be great. Thanks!

   👍React with 👍1Reacted by Rory Fuhrer
10. rory-orennia

    changed the title [-]SvelteKit builds are non-deterministic[/-] [+]svelte.config.js version changes cause most client chunks to generate a new hash despite no other changes[/+] on May 27, 2024
11. matindow commented on Jun 15, 2024

    

    matindow

    on Jun 15, 2024

    More actions

    Are there any proposals/thoughts for how to address this?

    How much worse would it be if the content in version.json were replaced with something like a junction map of component names => file paths that all of the chunks referenced dynamically? I am assuming there are a lot of really great/important benefits to being able to hardcode a static file import into all of the chunks that make this a non starter?

    I'm trying to think through other ways of doing this version check, and everything seems to come back to the same frictions.

    I do agree that incrementing the version number should intuitively not cascade into a new hash for unchanged files in your project, though. Seems not great even aside from the terrible caching issues.
12. dummdidumm

    closed this as completedin #12700on Oct 7, 2024
13. dummdidumm

    closed this as completedin 3591411on Oct 7, 2024
14. dummdidumm

    added a commit that references this issue on Oct 9, 2024

    Revert "fix: replace version in generateBundle (#12700)"

    ...

    2ffcc41
15. dummdidumm

    reopened this on Oct 9, 2024
16. teemingc

    added a commit that references this issue on Oct 9, 2024

    Revert "fix: replace version in generateBundle (#12700)" (#12779)

    ...

    13fb7f5
17. teemingc

    added

    bugSomething isn't workingSomething isn't working

    on Oct 16, 2024
18. teemingc

    added a parent issue on May 25, 2026

    • Deterministic version.name #14176
19. jippi commented on Jun 20, 2026

    

    jippi

    on Jun 20, 2026

    More actions

    This is a solution I came up with and running as experiment - summary by Claude because its 1am and I'm le tired

    1. Constant sentinel for kit.version.name

    // svelte.config.js
    const APP_VERSION = '__APP_VERSION__' // constant sentinel, NEVER the SHA
    kit: {
      version: { name: APP_VERSION, pollInterval: 60_000 },
    }

    Now version_hash is constant → globalThis.__sveltekit_<hash> is identical every deploy, and the bundled version string is constant → immutable chunks are byte-stable.

    2. Override the client-only version define to read a <meta> at runtime

    The bundled version must reflect the real build at runtime without baking the SHA. Override the client define so it reads a <meta> tag (constant code → no SHA in bytes):

    // vite.config.ts — a plugin AFTER sveltekit() in the plugins array
    {
      name: 'app-version-runtime',
      configEnvironment(name) {
        if (name !== 'client') return null
        return {
          define: {
            __SVELTEKIT_APP_VERSION__:
              `(typeof document!=='undefined'?(document.querySelector('meta[name="app-version"]')?.getAttribute('content')??''):'')`,
          },
        }
      },
    }

    $app/environment's version (and thus kit's updated check, your analytics, etc.) is now the real SHA at runtime, read once at module-eval from the <meta> parsed in <head> before any module script runs. Leave the server define alone.

    3. Inject the real SHA into that <meta> per request

    <!-- app.html, in <head> (before any module script). No comment with the marker in it — see gotcha. -->
    <meta name="app-version" content="%app_version%" />

    // a `handle` hook
    export const version_inject: Handle = ({ event, resolve }) => {
    	const sha = process.env.GIT_SHA || '__APP_VERSION__' // sentinel fallback when unset (local)
    	return resolve(event, {
    		transformPageChunk: ({ html }) => html.replaceAll('%app_version%', sha), // replaceAll, not replace
    	})
    }

    A <meta>, not an inline <script>: a script injected via transformPageChunk runs after SvelteKit computed its CSP nonce, so a strict script-src would block it; <meta> is not governed by script-src.

    4. Swap the sentinel → real SHA in the two NON-immutable outputs

    _app/version.json (the updated poll target) and service-worker.js (precache-${version}) carry the sentinel and DO need the real SHA. Both are served no-cache / revalidated — not immutable — so rewriting them is safe. Do it in a Vite closeBundle plugin (so vite build ≡ pnpm build — no separate post-build step to forget), gated on the SSR pass so it runs after the adapter assembles build/:

    // vite.config.ts plugin, ordered after sveltekit()
    let resolved
    {
      name: 'app-version-finalize',
      configResolved(c) { resolved = c },
      closeBundle: {
        order: 'post', sequential: true,
        handler() {
          if (!resolved?.build.ssr) return            // mirrors kit's adapter gating
          const sha = process.env.GIT_SHA
          if (!sha) return                            // local: leave the sentinel
          for (const f of ['build/client/_app/version.json', 'build/client/service-worker.js']) {
            writeFileSync(f, readFileSync(f, 'utf8').replaceAll('__APP_VERSION__', sha))
          }
          // guard: assert the SHA never appears under build/client/_app/immutable/**
        }
      }
    }

    Never touch build/client/_app/immutable/** — keeping the SHA out of those bytes is the entire point.

    Why this is correct

    • Built-in updated/reload-on-deploy keeps working, unchanged: the polled version.json (real SHA) is compared against the client version (real SHA from the <meta>) — real-vs-real. After a new deploy they differ → updated.current flips → reload on next nav. No custom detector needed.
    • Immune to the Revert "fix: replace version in generateBundle (#12700)" #12779 class by construction: no immutable byte ever changes. Filenames stay stable because the content is genuinely constant, not because we froze a name over drifting content.
    • Service-worker precache rotates per deploy (its file is re-fetched, not immutable); analytics version tagging stays real.

    Verify

    GIT_SHA=aaaaaaa pnpm build && find build/client/_app/immutable -type f | sed 's|.*/immutable/||' | sort > a.txt
    GIT_SHA=bbbbbbb pnpm build && find build/client/_app/immutable -type f | sed 's|.*/immutable/||' | sort > b.txt
    comm -3 a.txt b.txt   # expect: empty (only version.json + service-worker.js differ)

    In the browser: the <meta> carries the real SHA; version.json matches it; deploying a new build triggers exactly one reload-on-next-nav with no reload loop.

    Gotchas (each one bit us)

    • replaceAll, not replace. String.replace(str, …) swaps only the first occurrence. If anything else on the page contains the marker (e.g. an explanatory HTML comment above the <meta>), it absorbs the swap and the real attribute stays raw → the client reads the literal "%app_version%" → permanent version.json != "%app_version%" mismatch → reload on every navigation. Use replaceAll and don't put the marker in a comment.
    • Scope the define override to the client environment. The server importing version server-side would otherwise read document (undefined).
    • CSP: deliver via <meta>, not an injected inline <script>.

    Applicability

    Single SvelteKit app (no multi-app embedding on one page — a constant globalThis.__sveltekit_<hash> namespace is only a collision risk there). Tested with rolldown-vite; the same shape works on Rollup-Vite. Until SvelteKit ships a first-class fix for #12260, this keeps your immutable assets genuinely immutable across deploys.
20. michael-haberzettel commented on Jun 21, 2026

    

    michael-haberzettel

    on Jun 21, 2026

    More actions

    @jippi

    Du you tried to check the preload mechanism: https://svelte.dev/tutorial/kit/preload

    Some of my attempts failed because of this system.

    To test it, you can do these steps:

    • run build, preview and display a page in a browser with preloadable links without hovering them to not trigger mechanism.
    • stop the preview server and bring a change to page you want to navigate with preload.
    • run build, preview and go to your previous page, opened in the first step. Are you able to navigate to your preloadable link without errors ?
21. jippi commented on Jun 21, 2026

    

    jippi

    on Jun 21, 2026

    More actions

    @michael-haberzettel I use the preload system extensively ( https://mangabaka.org/ ) and haven't seen any errors - since my patch above doesn't change anything in svelte, other than the "source of the version value" it shouldn't really impact any behavior in svelte either - at least i haven't noticed anything the last 8-12 development hours since I put this online
22. michael-haberzettel commented on Jun 21, 2026

    

    michael-haberzettel

    on Jun 21, 2026

    More actions

    I will give it a try on next days 👍
23. teemingc

    linked a pull request that will close this issueMove version into payload to avoid rotating client chunks #16271on Jul 10, 2026
24. teemingc

    linked a pull request that will close this issuefix: preserve shared client chunk hashes when the app version changes #16324on Jul 13, 2026
25. Rich-Harris

    added a commit that references this issue on Jul 14, 2026

    fix: preserve shared client chunk hashes when the app version changes (…

    ...

    This issue will close once commit ab5c253 is merged into the 'main' branch.

    ab5c253
26. teemingc commented on Jul 16, 2026

    

    teemingc

    on Jul 16, 2026

    Member

    More actions

    Closed by #16324

    ❤️React with ❤️1Reacted by Maxime Quandalle

    🚀React with 🚀1Reacted by Rory Fuhrer
27. teemingc

    closed this as completedon Jul 16, 2026
28. Nic-Polumeyv

    removed

    bugSomething isn't workingSomething isn't working

    on Aug 4, 2026
29. Nic-Polumeyv

    added the

    Bug

    issue type on Aug 4, 2026