don't pass URL from server

[Rich-Harris]

The reasons for the previous way of doing things are somewhat cloudy — something to do with ensuring that we use the same route in the client as we do on the server, and with the same params, even if the page is prerendered and deployed somewhere that it doesn't expect to be.

But since those things are passed along separately, I think it's preferable to set the URL based on window.location — this means client-side access to search and hash (without weird hacks), and is arguably more correct, even if there is a risk of inconsistency in edge cases.

This will allow us to close #3650 and #3680.

No tests because it's a bit of an awkward thing to test for.

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 pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 25430e9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

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

[benmccann]

@Rich-Harris it looks like the tests are failing with this PR

[Rich-Harris]

the adapter-static changes were a red herring, but worth keeping anyway

[Conduitry]

Why is this adding devalue? Is that being used anywhere in these changes?

[Rich-Harris]

Why is this adding devalue? Is that being used anywhere in these changes?

Yeah, it allows adapter-static to test using src/cli.js rather than dist/cli.js — initially I thought the failing tests were in that package, and that was part of my attempt to debug. I was wrong (it was the prerender tests inside Kit, which use adapter-static) but it felt like a good change to keep anyway.

I'd quite like to get rid of the devalue dependency separately — we're only using it to prevent XSS vulns in params and session, and we could use an internal helper instead if we were happy insisting session be JSON-serializable — but that would be a separate chunk of work.

kit/packages/kit/src/runtime/server/page/render.js

Line 181 in 22a5e40

params: ${devalue(params)}

kit/packages/kit/src/runtime/server/page/render.js

Lines 332 to 339 in 22a5e40

	function try_serialize(data, fail) {
	try {
	return devalue(data);
	} catch (err) {
	if (fail) fail(coalesce_to_error(err));
	return null;
	}
	}

[johnnysprinkles]

I think this also fixes #1511. Rock on!