Sync kit docs (sveltejs#1135)

sync kit docs

Co-authored-by: svelte-docs-bot[bot] <196124396+svelte-docs-bot[bot]@users.noreply.github.com>

Author: github-actions[bot]

apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md

@@ -38,6 +38,8 @@ A `+page.svelte` component defines a page of your app. By default, pages are ren
 <a href="/">Home</a>
 ```
 
+> [!NOTE] SvelteKit uses `<a>` elements to navigate between routes, rather than a framework-specific `<Link>` component.
+
 Pages can receive data from `load` functions via the `data` prop.
 
 ```svelte
@@ -56,8 +58,6 @@ Pages can receive data from `load` functions via the `data` prop.
 >
 > In Svelte 4, you'd use `export let data` instead.
 
-> [!NOTE] SvelteKit uses `<a>` elements to navigate between routes, rather than a framework-specific `<Link>` component.
-
 ### +page.js
 
 Often, a page will need to load some data before it can be rendered. For this, we add a `+page.js` module that exports a `load` function:

apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md

@@ -354,7 +354,7 @@ The easiest way to progressively enhance a form is to add the `use:enhance` acti
 <form method="POST" +++use:enhance+++>
 ```
 
-> [!NOTE] `use:enhance` can only be used with forms that have `method="POST"`. It will not work with `method="GET"`, which is the default for forms without a specified method. Attempting to use `use:enhance` on forms without `method="POST"` will result in an error.
+> [!NOTE] `use:enhance` can only be used with forms that have `method="POST"` and point to actions defined in a `+page.server.js` file. It will not work with `method="GET"`, which is the default for forms without a specified method. Attempting to use `use:enhance` on forms without `method="POST"` or posting to a `+server.js` endpoint will result in an error.
 
 > [!NOTE] Yes, it's a little confusing that the `enhance` action and `<form action>` are both called 'action'. These docs are action-packed. Sorry.
 

apps/svelte.dev/content/docs/kit/60-appendix/30-migrating-to-sveltekit-2.md

@@ -130,7 +130,7 @@ The `$env/dynamic/public` and `$env/dynamic/private` modules provide access to _
 
 During prerendering in SvelteKit 1, they are one and the same. As such, prerendered pages that make use of 'dynamic' environment variables are really 'baking in' build time values, which is incorrect. Worse, `$env/dynamic/public` is populated in the browser with these stale values if the user happens to land on a prerendered page before navigating to dynamically-rendered pages.
 
-Because of this, dynamic environment variables can no longer be read during prerendering in SvelteKit 2 — you should use the `static` modules instead. If the user lands on a prerendered page, SvelteKit will request up-to-date values for `$env/dynamic/public` from the server (by default from a module called `_env.js` — this can be configured with `config.kit.env.publicModule`) instead of reading them from the server-rendered HTML.
+Because of this, dynamic environment variables can no longer be read during prerendering in SvelteKit 2 — you should use the `static` modules instead. If the user lands on a prerendered page, SvelteKit will request up-to-date values for `$env/dynamic/public` from the server (by default from a module called `/_app/env.js`) instead of reading them from the server-rendered HTML.
 
 ## `form` and `data` have been removed from `use:enhance` callbacks
 

apps/svelte.dev/content/docs/kit/98-reference/50-configuration.md

@@ -1085,6 +1085,41 @@ What type of client-side router to use.
 - `'hash'` means the route is determined by `location.hash`. In this case, SSR and prerendering are disabled. This is only recommended if `pathname` is not an option, for example because you don't control the webserver where your app is deployed.
 	It comes with some caveats: you can't use server-side rendering (or indeed any server logic), and you have to make sure that the links in your app all start with #/, or they won't work. Beyond that, everything works exactly like a normal SvelteKit app.
 
+</div>
+</div>
+<div class="ts-block-property">
+
+```ts
+// @noErrors
+resolution?: 'client' | 'server';
+```
+
+<div class="ts-block-property-details">
+
+<div class="ts-block-property-bullets">
+
+- <span class="tag">default</span> `"client"`
+- <span class="tag since">available since</span> v2.17.0
+
+</div>
+
+How to determine which route to load when navigating to a new page.
+
+By default, SvelteKit will serve a route manifest to the browser.
+When navigating, this manifest is used (along with the `reroute` hook, if it exists) to determine which components to load and which `load` functions to run.
+Because everything happens on the client, this decision can be made immediately. The drawback is that the manifest needs to be
+loaded and parsed before the first navigation can happen, which may have an impact if your app contains many routes.
+
+Alternatively, SvelteKit can determine the route on the server. This means that for every navigation to a path that has not yet been visited, the server will be asked to determine the route.
+This has several advantages:
+- The client does not need to load the routing manifest upfront, which can lead to faster initial page loads
+- The list of routes is hidden from public view
+- The server has an opportunity to intercept each navigation (for example through a middleware), enabling (for example) A/B testing opaque to SvelteKit
+
+The drawback is that for unvisited paths, resolution will take slightly longer (though this is mitigated by [preloading](/docs/kit/link-options#data-sveltekit-preload-data)).
+
+> [!NOTE] When using server-side route resolution and prerendering, the resolution is prerendered along with the route itself.
+
 </div>
 </div>
 

apps/svelte.dev/content/docs/kit/98-reference/54-types.md

@@ -128,15 +128,34 @@ The generated `.svelte-kit/tsconfig.json` file contains a mixture of options. So
 /// file: .svelte-kit/tsconfig.json
 {
 	"compilerOptions": {
-		"baseUrl": "..",
 		"paths": {
-			"$lib": "src/lib",
-			"$lib/*": "src/lib/*"
+			"$lib": ["../src/lib"],
+			"$lib/*": ["../src/lib/*"]
 		},
 		"rootDirs": ["..", "./types"]
 	},
-	"include": ["../src/**/*.js", "../src/**/*.ts", "../src/**/*.svelte"],
-	"exclude": ["../node_modules/**", "./**"]
+	"include": [
+		"ambient.d.ts",
+		"non-ambient.d.ts",
+		"./types/**/$types.d.ts",
+		"../vite.config.js",
+		"../vite.config.ts",
+		"../src/**/*.js",
+		"../src/**/*.ts",
+		"../src/**/*.svelte",
+		"../tests/**/*.js",
+		"../tests/**/*.ts",
+		"../tests/**/*.svelte"
+	],
+	"exclude": [
+		"../node_modules/**",
+		"../src/service-worker.js",
+		"../src/service-worker/**/*.js",
+		"../src/service-worker.ts",
+		"../src/service-worker/**/*.ts",
+		"../src/service-worker.d.ts",
+		"../src/service-worker/**/*.d.ts"
+	]
 }
 ```
 
@@ -148,24 +167,22 @@ Others are required for SvelteKit to work properly, and should also be left unto
 	"compilerOptions": {
 		// this ensures that types are explicitly
 		// imported with `import type`, which is
-		// necessary as svelte-preprocess cannot
+		// necessary as Svelte/Vite cannot
 		// otherwise compile components correctly
-		"importsNotUsedAsValues": "error",
+		"verbatimModuleSyntax": true,
 
 		// Vite compiles one TypeScript module
 		// at a time, rather than compiling
 		// the entire module graph
 		"isolatedModules": true,
 
-		// TypeScript cannot 'see' when you
-		// use an imported value in your
-		// markup, so we need this
-		"preserveValueImports": true,
+		// Tell TS it's used only for type-checking
+		"noEmit": true,
 
 		// This ensures both `vite build`
 		// and `svelte-package` work correctly
 		"lib": ["esnext", "DOM", "DOM.Iterable"],
-		"moduleResolution": "node",
+		"moduleResolution": "bundler",
 		"module": "esnext",
 		"target": "esnext"
 	}