chore: split $app/state into client/server halves - #16801
Merged
Conversation
|
Install the latest version of pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/76c6838f83e6cc2a2ee709eb302e9fc97ea60329Open in |
|
Rich-Harris
commented
Aug 14, 2026
| }, | ||
| props: { | ||
| page, | ||
| page: { ...page }, |
Member
Author
There was a problem hiding this comment.
this was a latent bug that would likely have come to bite us eventually — we were mutating the actual page object later (navigation_result.props.page.foo = bar) when we should only ever mutate a copy
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
…tches the import source `#app/state/client`, so the spec fails to load with a ReferenceError.
This commit fixes the issue reported at packages/kit/src/runtime/client/remote-functions/shared.transport.spec.js:16
## Bug
After the module split, `shared.svelte.js` now imports its reactive state from `#app/state/client`:
```js
import { navigating, page, notify_version } from '#app/state/client';
```
But `shared.transport.spec.js` still mocked the old path:
```js
vi.mock(new URL('../state.svelte.js', import.meta.url).pathname, () => ({ ... }));
```
Since that path is no longer imported by `shared.svelte.js`, the mock intercepts nothing. Vitest then loads the real `#app/state/client` → `src/runtime/app/state/client.svelte.js`, which references the build-time global `__SVELTEKIT_APP_VERSION_POLL_INTERVAL__` at module top-level. That global is not defined/stubbed in the test environment, so the module throws:
```
ReferenceError: __SVELTEKIT_APP_VERSION_POLL_INTERVAL__ is not defined
❯ src/runtime/app/state/client.svelte.js:131
❯ src/runtime/client/remote-functions/shared.svelte.js:9
❯ src/runtime/client/remote-functions/shared.transport.spec.js:23
```
The whole spec file fails to load — 0 tests run.
## Fix
Point the mock at the actual import specifier `#app/state/client`:
```js
vi.mock('#app/state/client', () => ({
navigating: { current: null },
page: { url: new URL('http://localhost/') },
updated: { current: false, check: () => Promise.resolve(false) },
notify_version: () => {}
}));
```
## Verification
```
npx vitest run --config vitest.kit.config.js --project kit-client-runtime \
src/runtime/client/remote-functions/shared.transport.spec.js
```
Before: `FAIL (0 test)` with the ReferenceError. After: `1 passed (1)` file, `3 passed (3)` tests.
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: Rich-Harris <hello@rich-harris.dev>
…eset invalidations because the preserved values are written before `apply_navigation_result` overwrites them
This commit fixes the issue reported at packages/kit/src/runtime/client/client.js:655
## Bug
In `_invalidate` (`packages/kit/src/runtime/client/client.js` ~line 655), the refactor to use `update_page(...)` reversed the effective order of operations relative to the original code.
**Original code:**
```js
if (!reset_page_state) {
navigation_result.props.page.state = prev_state;
}
navigation_result.props.page.shallow = prev_shallow;
apply_navigation_result(navigation_result);
```
This mutated the *page object inside the navigation result*, so when `apply_navigation_result` later did `Object.assign(page, result.props.page)`, the preserved `prev_state`/`prev_shallow` values were the ones assigned — they won.
**Refactored (buggy) code:**
```js
if (!reset_page_state) {
update_page({ state: prev_state }); // writes to internal_page
}
update_page({ shallow: prev_shallow }); // writes to internal_page
apply_navigation_result(navigation_result); // update_page(result.props.page) → Object.assign(internal_page, ...)
```
Now the preserved values are written to `internal_page` *first*, then `apply_navigation_result` calls `update_page(result.props.page)` which does `Object.assign(internal_page, result.props.page)`, clobbering them.
## Concrete trigger
In `get_navigation_result_from_branch`, when `page_changed` is true (the normal invalidation case, since `data_changed` makes `page_changed` true), `result.props.page` is rebuilt as a fresh object containing:
```js
state: {},
shallow: null,
```
So on any invalidation that changes data (e.g. `refresh`/`refreshAll` via `_invalidate(false)`), `apply_navigation_result` overwrites the just-restored `prev_state` with `{}` and `prev_shallow` with `null`. Result: `page.state` set through `goto`/shallow routing is lost, and `page.shallow` is reset to `null`, even though the caller requested state preservation (`reset_page_state === false`).
## Fix
Move the `update_page({ state: prev_state })` / `update_page({ shallow: prev_shallow })` calls to run *after* `apply_navigation_result(navigation_result)`, so the preserved values are applied last and win — matching the original `Object.assign(page, result.props.page)` ordering semantics.
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: Rich-Harris <hello@rich-harris.dev>
teemingc
approved these changes
Aug 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #16795 — this applies the same thinking to
$app/state. It allows us to get rid of the awfulBROWSERhack and colocate logic more sensibly, with less indirection.Again, no changeset, since no user-observable changes.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.Edits