move config.kit.hydrate and config.kit.router to config.kit.browser

[Rich-Harris]

Companion to #3576

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: 8763832

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

[netlify]

✔️ Deploy Preview for kit-demo canceled.

🔨 Explore the source changes: 8763832

🔍 Inspect the deploy log: https://app.netlify.com/sites/kit-demo/deploys/61f463d5000ad100071359e7

[benmccann]

really not a fan of this one to be honest

browser.router reads very strangely to me since we refer to it as client-side routing. we never call it browser routing or the browser router

I don't think has to match import { browser } from '$app/env'. They're relatively separate. If we did want to make them match I'd rather rename browser to client, but I don't really think it's worth the churn

[Rich-Harris]

We should definitely try to use language consistently — either both browser or both client.

browser:

👍 unambiguous
👎 wouldn't make as much sense if we started supporting e.g. Electron apps

client:

👍 mirrors 'client-side routing'
👍 would make sense to have import { client, server } from '$app/env — { browser, server } feels odd
👎 breaking change

The last 👎 is a big one, unfortunately. I don't think there's a way to detect the use of browser and throw a helpful error, we would just have to break people's apps and hope that they had a way to figure it out.

[benmccann]

Could we make a proxy so that whenever you access browser it logs a warning?

[Rich-Harris]

nope, proxies don't work like that. a module can't expose a proxy of itself

[Rich-Harris]

from @pngwn in discord:

I much much prefer browser over client. Client gets use for so many things even with a web dev context that it is confusing. Browser is very clear.
Happy for us to start using the phrase ‘browser routing’

I agree with that, we talk about 'API clients' and what-have-you — you can imagine code like this:

const client = browser ? get_browser_client() : get_server_client();

Between that and the breaking-ness of the change, I think we should merge this as-is