Sync kit docs (#1351)

github-actions[bot] · svelte-docs-bot[bot] · web-flow · commit 04a364551d8f · 2025-05-18T16:30:33.000-04:00
sync kit docs

Co-authored-by: svelte-docs-bot[bot] &lt;196124396+svelte-docs-bot[bot]@users.noreply.github.com&gt;
diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/40-page-options.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/40-page-options.md
@@ -3,7 +3,7 @@ NOTE: do not edit this file, it is generated in apps/svelte.dev/scripts/sync-doc
 title: Page options
 ---
 
-By default, SvelteKit will render (or [prerender](glossary#Prerendering)) any component first on the server and send it to the client as HTML. It will then render the component again in the browser to make it interactive in a process called [**hydration**](glossary#Hydration). For this reason, you need to ensure that components can run in both places. SvelteKit will then initialize a [**router**](routing) that takes over subsequent navigations.
+By default, SvelteKit will render (or [prerender](glossary#Prerendering)) any component first on the server and send it to the client as HTML. It will then render the component again in the browser to make it interactive in a process called [_hydration_](glossary#Hydration). For this reason, you need to ensure that components can run in both places. SvelteKit will then initialize a [_router_](routing) that takes over subsequent navigations.
 
 You can control each of these on a page-by-page basis by exporting options from [`+page.js`](routing#page-page.js) or [`+page.server.js`](routing#page-page.server.js), or for groups of pages using a shared [`+layout.js`](routing#layout-layout.js) or [`+layout.server.js`](routing#layout-layout.server.js). To define an option for the whole app, export it from the root layout. Child layouts and pages override values set in parent layouts, so — for example — you can enable prerendering for your entire app then disable it for pages that need to be dynamically rendered.
 
diff --git a/apps/svelte.dev/content/docs/kit/25-build-and-deploy/60-adapter-cloudflare.md b/apps/svelte.dev/content/docs/kit/25-build-and-deploy/60-adapter-cloudflare.md
@@ -109,9 +109,9 @@ Please follow the [Get Started Guide](https://developers.cloudflare.com/pages/ge
 
 If you're using the [Git integration](https://developers.cloudflare.com/pages/get-started/git-integration/), your build settings should look like this:
 
-- **Framework preset** – SvelteKit
-- **Build command** – `npm run build` or `vite build`
-- **Build output directory** – `.svelte-kit/cloudflare`
+- Framework preset – SvelteKit
+- Build command – `npm run build` or `vite build`
+- Build output directory – `.svelte-kit/cloudflare`
 
 ### Further reading
 
@@ -158,7 +158,7 @@ export {};
 
 Cloudflare specific values in the `platform` property are emulated during dev and preview modes. Local [bindings](https://developers.cloudflare.com/workers/wrangler/configuration/#bindings) are created based on your [Wrangler configuration file](https://developers.cloudflare.com/workers/wrangler/) and are used to populate `platform.env` during development and preview. Use the adapter config [`platformProxy` option](#Options-platformProxy) to change your preferences for the bindings.
 
-For testing the build, you should use [Wrangler](https://developers.cloudflare.com/workers/wrangler/) **version 4**. Once you have built your site, run `wrangler dev .svelte-kit/cloudflare` if you're testing for Cloudflare Workers or `wrangler pages dev .svelte-kit/cloudflare` for Cloudflare Pages.
+For testing the build, you should use [Wrangler](https://developers.cloudflare.com/workers/wrangler/) version 4. Once you have built your site, run `wrangler dev .svelte-kit/cloudflare` if you're testing for Cloudflare Workers or `wrangler pages dev .svelte-kit/cloudflare` for Cloudflare Pages.
 
 ## Headers and redirects
 
diff --git a/apps/svelte.dev/content/docs/kit/25-build-and-deploy/70-adapter-cloudflare-workers.md b/apps/svelte.dev/content/docs/kit/25-build-and-deploy/70-adapter-cloudflare-workers.md
@@ -113,7 +113,7 @@ export {};
 
 Cloudflare Workers specific values in the `platform` property are emulated during dev and preview modes. Local [bindings](https://developers.cloudflare.com/workers/wrangler/configuration/#bindings) are created based on your [Wrangler configuration file](https://developers.cloudflare.com/workers/wrangler/) and are used to populate `platform.env` during development and preview. Use the adapter config [`platformProxy` option](#Options-platformProxy) to change your preferences for the bindings.
 
-For testing the build, you should use [Wrangler](https://developers.cloudflare.com/workers/wrangler/) **version 4**. Once you have built your site, run `wrangler dev`.
+For testing the build, you should use [Wrangler](https://developers.cloudflare.com/workers/wrangler/) version 4. Once you have built your site, run `wrangler dev`.
 
 ## Troubleshooting
 
diff --git a/apps/svelte.dev/content/docs/kit/30-advanced/20-hooks.md b/apps/svelte.dev/content/docs/kit/30-advanced/20-hooks.md
@@ -107,7 +107,7 @@ Note that `resolve(...)` will never throw an error, it will always return a `Pro
 
 ### handleFetch
 
-This function allows you to modify (or replace) a `fetch` request that happens inside a `load`, `action` or `handle` function that runs on the server (or during prerendering).
+This function allows you to modify (or replace) the result of an [`event.fetch`](load#Making-fetch-requests) call that runs on the server (or during prerendering) inside an endpoint, `load`, `action`, `handle`, `handleError` or `reroute`.
 
 For example, your `load` function might make a request to a public URL like `https://api.yourapp.com` when the user performs a client-side navigation to the respective page, but during SSR it might make sense to hit the API directly (bypassing whatever proxies and load balancers sit between it and the public internet).
 
@@ -127,13 +127,9 @@ export async function handleFetch({ request, fetch }) {
 }
 ```
 
-**Credentials**
+Requests made with `event.fetch` follow the browser's credentials model — for same-origin requests, `cookie` and `authorization` headers are forwarded unless the `credentials` option is set to `"omit"`. For cross-origin requests, `cookie` will be included if the request URL belongs to a subdomain of the app — for example if your app is on `my-domain.com`, and your API is on `api.my-domain.com`, cookies will be included in the request.
 
-For same-origin requests, SvelteKit's `fetch` implementation will forward `cookie` and `authorization` headers unless the `credentials` option is set to `"omit"`.
-
-For cross-origin requests, `cookie` will be included if the request URL belongs to a subdomain of the app — for example if your app is on `my-domain.com`, and your API is on `api.my-domain.com`, cookies will be included in the request.
-
-If your app and your API are on sibling subdomains — `www.my-domain.com` and `api.my-domain.com` for example — then a cookie belonging to a common parent domain like `my-domain.com` will _not_ be included, because SvelteKit has no way to know which domain the cookie belongs to. In these cases you will need to manually include the cookie using `handleFetch`:
+There is one caveat: if your app and your API are on sibling subdomains — `www.my-domain.com` and `api.my-domain.com` for example — then a cookie belonging to a common parent domain like `my-domain.com` will _not_ be included, because SvelteKit has no way to know which domain the cookie belongs to. In these cases you will need to manually include the cookie using `handleFetch`:
 
 ```js
 /// file: src/hooks.server.js
diff --git a/apps/svelte.dev/content/docs/kit/60-appendix/10-faq.md b/apps/svelte.dev/content/docs/kit/60-appendix/10-faq.md
@@ -194,9 +194,7 @@ Sort of. The Plug'n'Play feature, aka 'pnp', is broken (it deviates from the Nod
 
 Currently ESM Support within the latest Yarn (version 3) is considered [experimental](https://github.com/yarnpkg/berry/pull/2161).
 
-The below seems to work although your results may vary.
-
-First create a new application:
+The below seems to work although your results may vary. First create a new application:
 
 ```sh
 yarn create svelte myapp
@@ -210,8 +208,6 @@ yarn set version berry
 yarn install
 ```
 
-#### Yarn 3 global cache
-
 One of the more interesting features of Yarn Berry is the ability to have a single global cache for packages, instead of having multiple copies for each project on the disk. However, setting `enableGlobalCache` to true causes building to fail, so it is recommended to add the following to the `.yarnrc.yml` file:
 
 ```yaml
diff --git a/apps/svelte.dev/content/docs/kit/98-reference/10-@sveltejs-kit.md b/apps/svelte.dev/content/docs/kit/98-reference/10-@sveltejs-kit.md
@@ -1110,7 +1110,7 @@ type HandleClientError = (input: {
 
 ## HandleFetch
 
-The [`handleFetch`](/docs/kit/hooks#Server-hooks-handleFetch) hook allows you to modify (or replace) a `fetch` request that happens inside a `load` function that runs on the server (or during prerendering).
+The [`handleFetch`](/docs/kit/hooks#Server-hooks-handleFetch) hook allows you to modify (or replace) the result of an [`event.fetch`](/docs/kit/load#Making-fetch-requests) call that runs on the server (or during prerendering) inside an endpoint, `load`, `action`, `handle`, `handleError` or `reroute`.
 
 <div class="ts-block">
 
