fix: don't redirect in forks#16292
Conversation
This prevents a redirect that a remote function could do from doing a navigation in a fork. It's implemented by putting the context into fork, pulling it out on remote function invocation to check if we're in a fork, put that into a map, and pull it out of there when a redirect occurs to check if the remote function is only called in context of that fork, and if so instead of redirecting we tell the SvelteKit router that this new route will redirect elsewhere. In the future we could follow that redirect and run it in the fork, but this is good enough for now and ties nicely into the current SvelteKit router. Fixes #14935
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @sveltejs/kit@2.69.2 ### Patch Changes - fix: set `define` values on `globalThis` when running Vitest ([#16246](#16246)) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The action won't run unless it's on `main` so #16254 needs to be backported. Not sure if the instrumentation test app and job also needs to be backported for the one on `version-3` to run
|
Install the latest version of pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/d9e61fec11f2a475957b055ecb245fd5fcd0e09fOpen in |
|
|
I wonder if we can use |
| let data = $derived({${levels.map((l) => `'${l}': data_${l}`).join(', ')}}); | ||
|
|
||
| if (browser) { | ||
| setContext('__sveltekit_fork', () => fork); |
There was a problem hiding this comment.
why would we use context here rather than just importing from a shared module?
3 participants
This prevents a redirect that a remote function could do from doing a navigation in a fork.
Leverages Svelte's new forking methods from sveltejs/svelte#17217(no longer needs those, but having committed/discarded would be nice)It's implemented by putting the context into fork, pulling it out on remote function invocation to check if we're in a fork (TODO what if you have it invoked elsewhere and you just await it in a fork context?), put that into a map, and pull it out of there when a redirect occurs to check if the remote function is only called in context of that fork, and if so instead of redirecting we tell the SvelteKit router that this new route will redirect elsewhere. In the future we could follow that redirect and run it in the fork, but this is good enough for now and ties nicely into the current SvelteKit router.
Fixes #14935