Move version into payload to avoid rotating client chunks

[Axeldeblen]

closes
#12260
#9576

---

Somewhat adjacent to #14176

Context

For context we're running a svelte kit app and deploying many times per day. Currently svelte kit places the version into the client bundle, causing the chunks to rotate their hashes invalidating the caching whenever we deploy as described in #12260. This contributes to a degraded user experience in our case .e.g. a user will open a modal but the chunk will 404's the client chunks because the server version has rotated. We're using our git SHA as our version.

Description

This PR aims to solve the bundle rotating by refactoring the mechanism of how svelte kit defines and deliver the version within each client / server context.

Here is a simple visual flow of how the current version leaks into the client bundle via two seperate sources.

[see](https://vite.dev/config/shared-options#define) for how __SVELTEKIT_PAYLOAD__ is replaced by vite

kit.version.name  = 'version-alpha'
        │
        ├─▶ __sveltekit/environment emits  export const version = "version-alpha"
        │       └─▶ imported by runtime/client/utils.js (the `updated` poll)
        │
        └─▶ version_hash = hash(name)  ─▶  __SVELTEKIT_PAYLOAD__ (vite define  replacement)
                                            = globalThis.__sveltekit_<version_hash> -▶ __sveltekit__99avfu
        │
        ▼
both inlined into ONE shared client chunk   ←  its bytes change resulting in its content hash changing
        │ 
        ▼
every chunk that imports it gets a new hash  ← causes cascade effect across the entire client bundle
(entry/app, entry/start, nodes/*, other shared chunks)

Because the client uses the version hash as part of the global definition we need to keep it stable if we want to avoid the cascade effect.

For that reason we are using a combination of config values to avoid any global collisions in embedded sveltekit version like in #14176

hash(`${name}\n${kit.paths.base}\n${kit.appDir}`);

(Open to other suggestions on other combinations here)

Now the version_hash is stable on globalThis between deploys we pass the actual version through the payload.

Then we pass the version as a prop within the payload

	const properties = [
			`base: ${base_expression}`,
			`version: ${devalue.uneval(__SVELTEKIT_APP_VERSION__)}`
		];

N.B Perhaps version_hash needs to be renamed now as our definitions of "version" diverge a bit. I'd like to get a bit more feedback on the general approach here before continuing further refactoring.

Tests

I've added some tests to demonstrate the current issue. In these tests we build multiple versions of the app with different version inputs and compare the content of the built chunks to avoid running into situations similar to #12779 (even though we are not using post build plugins).

Production testing

Our app is currently pinned to a slightly older version of kit but we're happy to test the core of these changes out on a subset of production traffic to help verify.

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

I haven't made a change set yet but I will on confirmation the maintainers are happy with the direction of this PR.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[pkg-svelte-dev]

Install the latest version of @sveltejs/kit from db64f31:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/db64f31ae89c037d168a56e53845284c98ac888e

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16271

Note

This PR is from a fork. A maintainer must approve approve each commit before it can be built and installed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: db64f31

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

Unresolved git merge conflict markers were committed in packages/kit/src/core/utils.js, producing invalid JavaScript that breaks parsing/build of the entire kit package.