site: sync to current svelte.dev (#10187)

Author: PuruVJ

documentation/docs/20-core-concepts/10-routing.md

@@ -19,20 +19,20 @@ Each route directory contains one or more _route files_, which can be identified
 A `+page.svelte` component defines a page of your app. By default, pages are rendered both on the server ([SSR](glossary#ssr)) for the initial request and in the browser ([CSR](glossary#csr)) for subsequent navigation.
 
 ```svelte
-/// file: src/routes/+page.svelte
+<!--- file: src/routes/+page.svelte --->
 <h1>Hello and welcome to my site!</h1>
 <a href="/about">About my site</a>
 ```
 
 ```svelte
-/// file: src/routes/about/+page.svelte
+<!--- file: src/routes/about/+page.svelte --->
 <h1>About this site</h1>
 <p>TODO...</p>
 <a href="/">Home</a>
 ```
 
 ```svelte
-/// file: src/routes/blog/[slug]/+page.svelte
+<!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;
@@ -119,7 +119,7 @@ A `+page.server.js` file can also export _actions_. If `load` lets you read data
 If an error occurs during `load`, SvelteKit will render a default error page. You can customise this error page on a per-route basis by adding an `+error.svelte` file:
 
 ```svelte
-/// file: src/routes/blog/[slug]/+error.svelte
+<!--- file: src/routes/blog/[slug]/+error.svelte --->
 <script>
 	import { page } from '$app/stores';
 </script>
@@ -188,7 +188,7 @@ Layouts can be _nested_. Suppose we don't just have a single `/settings` page, b
 We can create a layout that only applies to pages below `/settings` (while inheriting the root layout with the top-level nav):
 
 ```svelte
-/// file: src/routes/settings/+layout.svelte
+<!--- file: src/routes/settings/+layout.svelte --->
 <script>
 	/** @type {import('./$types').LayoutData} */
 	export let data;
@@ -229,7 +229,7 @@ If a `+layout.js` exports [page options](page-options) — `prerender`, `ssr` an
 Data returned from a layout's `load` function is also available to all its child pages:
 
 ```svelte
-/// file: src/routes/settings/profile/+page.svelte
+<!--- file: src/routes/settings/profile/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;
@@ -286,7 +286,7 @@ If an error is thrown (either `throw error(...)` or an unexpected error), the re
 By exporting `POST`/`PUT`/`PATCH`/`DELETE`/`OPTIONS`/`HEAD` handlers, `+server.js` files can be used to create a complete API:
 
 ```svelte
-/// file: src/routes/add/+page.svelte
+<!--- file: src/routes/add/+page.svelte --->
 <script>
 	let a = 0;
 	let b = 0;
@@ -340,7 +340,7 @@ Throughout the examples above, we've been importing types from a `$types.d.ts` f
 For example, annotating `export let data` with `PageData` (or `LayoutData`, for a `+layout.svelte` file) tells TypeScript that the type of `data` is whatever was returned from `load`:
 
 ```svelte
-/// file: src/routes/blog/[slug]/+page.svelte
+<!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;

documentation/docs/20-core-concepts/20-load.md

@@ -22,7 +22,7 @@ export function load({ params }) {
 ```
 
 ```svelte
-/// file: src/routes/blog/[slug]/+page.svelte
+<!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;
@@ -83,7 +83,7 @@ export async function load() {
 ```
 
 ```svelte
-/// file: src/routes/blog/[slug]/+layout.svelte
+<!--- file: src/routes/blog/[slug]/+layout.svelte --->
 <script>
 	/** @type {import('./$types').LayoutData} */
 	export let data;
@@ -141,7 +141,7 @@ The `+page.svelte` component, and each `+layout.svelte` component above it, has
 In some cases, we might need the opposite — a parent layout might need to access page data or data from a child layout. For example, the root layout might want to access a `title` property returned from a `load` function in `+page.js` or `+page.server.js`. This can be done with `$page.data`:
 
 ```svelte
-/// file: src/routes/+layout.svelte
+<!--- file: src/routes/+layout.svelte --->
 <script>
 	import { page } from '$app/stores';
 </script>
@@ -341,7 +341,7 @@ export async function load({ parent }) {
 ```
 
 ```svelte
-/// file: src/routes/abc/+page.svelte
+<!--- file: src/routes/abc/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;
@@ -464,7 +464,7 @@ export function load() {
 This is useful for creating skeleton loading states, for example:
 
 ```svelte
-/// file: src/routes/+page.svelte
+<!--- file: src/routes/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;
@@ -569,7 +569,7 @@ export async function load({ fetch, depends }) {
 ```
 
 ```svelte
-/// file: src/routes/random-number/+page.svelte
+<!--- file: src/routes/random-number/+page.svelte --->
 <script>
 	import { invalidate, invalidateAll } from '$app/navigation';
 

documentation/docs/20-core-concepts/30-form-actions.md

@@ -23,7 +23,7 @@ export const actions = {
 To invoke this action from the `/login` page, just add a `<form>` — no JavaScript needed:
 
 ```svelte
-/// file: src/routes/login/+page.svelte
+<!--- file: src/routes/login/+page.svelte --->
 <form method="POST">
 	<label>
 		Email
@@ -71,12 +71,12 @@ export const actions = {
 To invoke a named action, add a query parameter with the name prefixed by a `/` character:
 
 ```svelte
-/// file: src/routes/login/+page.svelte
+<!--- file: src/routes/login/+page.svelte --->
 <form method="POST" action="?/register">
 ```
 
 ```svelte
-/// file: src/routes/+layout.svelte
+<!--- file: src/routes/+layout.svelte --->
 <form method="POST" action="/login?/register">
 ```
 
@@ -133,7 +133,7 @@ export const actions = {
 ```
 
 ```svelte
-/// file: src/routes/login/+page.svelte
+<!--- file: src/routes/login/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;
@@ -401,7 +401,7 @@ In all cases, [focus will be reset](accessibility#focus-management).
 We can also implement progressive enhancement ourselves, without `use:enhance`, with a normal event listener on the `<form>`:
 
 ```svelte
-/// file: src/routes/login/+page.svelte
+<!--- file: src/routes/login/+page.svelte --->
 <script>
 	import { invalidateAll, goto } from '$app/navigation';
 	import { applyAction, deserialize } from '$app/forms';
@@ -456,7 +456,7 @@ const response = await fetch(this.action, {
 Form actions are the preferred way to send data to the server, since they can be progressively enhanced, but you can also use [`+server.js`](routing#server) files to expose (for example) a JSON API. Here's how such an interaction could look like:
 
 ```svelte
-/// file: send-message/+page.svelte
+<!--- file: send-message/+page.svelte --->
 <script>
 	function rerun() {
 		fetch('/api/ci', {
@@ -469,7 +469,7 @@ Form actions are the preferred way to send data to the server, since they can be
 ```
 
 ```js
-// @errors: 2355 1360
+// @errors: 2355 1360 2322
 /// file: api/ci/+server.js
 
 /** @type {import('./$types').RequestHandler} */

documentation/docs/20-core-concepts/50-state-management.md

@@ -84,7 +84,7 @@ If you're not using SSR, then there's no risk of accidentally exposing one user'
 You might wonder how we're able to use `$page.data` and other [app stores](modules#$app-stores) if we can't use our own stores. The answer is that app stores on the server use Svelte's [context API](https://learn.svelte.dev/tutorial/context-api) — the store is attached to the component tree with `setContext`, and when you subscribe you retrieve it with `getContext`. We can do the same thing with our own stores:
 
 ```svelte
-/// file: src/routes/+layout.svelte
+<!--- file: src/routes/+layout.svelte --->
 <script>
 	import { setContext } from 'svelte';
 	import { writable } from 'svelte/store';
@@ -102,7 +102,7 @@ You might wonder how we're able to use `$page.data` and other [app stores](modul
 ```
 
 ```svelte
-/// file: src/routes/user/+page.svelte
+<!--- file: src/routes/user/+page.svelte --->
 <script>
 	import { getContext } from 'svelte';
 
@@ -122,7 +122,7 @@ If you're not using SSR (and can guarantee that you won't need to use SSR in fut
 When you navigate around your application, SvelteKit reuses existing layout and page components. For example, if you have a route like this...
 
 ```svelte
-/// file: src/routes/blog/[slug]/+page.svelte
+<!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
 	/** @type {import('./$types').PageData} */
 	export let data;

documentation/docs/25-build-and-deploy/90-adapter-vercel.md

@@ -120,7 +120,7 @@ export function load() {
 ```
 
 ```svelte
-/// file: +layout.svelte
+<!--- file: +layout.svelte --->
 <script>
 	/** @type {import('./$types').LayoutServerData} */
 	export let data;

documentation/docs/30-advanced/10-advanced-routing.md

@@ -254,7 +254,7 @@ src/routes/
 Not all use cases are suited for layout grouping, nor should you feel compelled to use them. It might be that your use case would result in complex `(group)` nesting, or that you don't want to introduce a `(group)` for a single outlier. It's perfectly fine to use other means such as composition (reusable `load` functions or Svelte components) or if-statements to achieve what you want. The following example shows a layout that rewinds to the root layout and reuses components and functions that other layouts can also use:
 
 ```svelte
-/// file: src/routes/nested/route/[email protected]
+<!--- file: src/routes/nested/route/[email protected] --->
 <script>
 	import ReusableLayout from '$lib/ReusableLayout.svelte';
 	export let data;

documentation/docs/30-advanced/25-errors.md

@@ -43,7 +43,7 @@ export async function load({ params }) {
 This tells SvelteKit to set the response status code to 404 and render an [`+error.svelte`](routing#error) component, where `$page.error` is the object provided as the second argument to `error(...)`.
 
 ```svelte
-/// file: src/routes/+error.svelte
+<!--- file: src/routes/+error.svelte --->
 <script>
 	import { page } from '$app/stores';
 </script>

documentation/docs/30-advanced/65-snapshots.md

@@ -9,7 +9,7 @@ For example, if the user fills out a form but clicks a link before submitting, t
 To do this, export a `snapshot` object with `capture` and `restore` methods from a `+page.svelte` or `+layout.svelte`:
 
 ```svelte
-/// file: +page.svelte
+<!--- file: +page.svelte --->
 <script>
 	let comment = '';
 

documentation/docs/40-best-practices/10-accessibility.md

@@ -17,7 +17,7 @@ Since navigation between pages in SvelteKit happens without reloading the page (
 Because of this behavior, every page in your app should have a unique, descriptive title. In SvelteKit, you can do this by placing a `<svelte:head>` element on each page:
 
 ```svelte
-/// file: src/routes/+page.svelte
+<!--- file: src/routes/+page.svelte --->
 <svelte:head>
 	<title>Todo List</title>
 </svelte:head>

documentation/docs/50-reference/40-types.md

@@ -22,10 +22,10 @@ The `RequestHandler` and `Load` types both accept a `Params` argument allowing y
 /// file: src/routes/[foo]/[bar]/[baz]/+page.server.js
 // @errors: 2355 2322 1360
 /** @type {import('@sveltejs/kit').RequestHandler<{
- *   foo: string;
- *   bar: string;
- *   baz: string
- * }>} */
+    foo: string;
+    bar: string;
+    baz: string
+  }>} */
 export async function GET({ params }) {
 	// ...
 }
@@ -98,7 +98,7 @@ export async function load({ params, fetch }) {
 
 > For this to work, your own `tsconfig.json` or `jsconfig.json` should extend from the generated `.svelte-kit/tsconfig.json` (where `.svelte-kit` is your [`outDir`](configuration#outdir)):
 >
->     { "extends": "./.svelte-kit/tsconfig.json" }
+> `{ "extends": "./.svelte-kit/tsconfig.json" }`
 
 ### Default tsconfig.json