Merge branch 'main' into hover

Author: Rich-Harris

apps/svelte.dev/content/blog/2024-12-01-advent-of-svelte.md

@@ -99,25 +99,48 @@ As of today, you can also return things that _aren't_ built in to the language,
 - [docs](/docs/kit/hooks#Universal-hooks-transport)
 - [demo](https://stackblitz.com/edit/sveltejs-kit-template-default-b5zbxomg?file=src%2Fhooks.js)
 
-## Day 13
+## Day 13: rise of the robots
 
-Coming soon!
+For those of you using LLMs to help you write code — via Cursor or Copilot or Claude or Bolt or v0 or some other interface — we now publish the documentation in a selection of robot-friendly `llms.txt` files. This is experimental and will evolve over time, but by way of example here's a [snake game](/playground/0de3c1c1a31d47bdbb7c4aa3477a6b46) built by Sonnet 3.5 with no additional prompting.
 
-## Day 14
+Thanks to [Didier Catz](https://x.com/didiercatz) and [Stanislav Khromov](https://bsky.app/profile/khromov.se) for building this!
 
-Coming soon!
+- [docs](/docs/llms)
 
-## Day 15
+## Day 14: unmount with outros
 
-Coming soon!
+Now, if you need to programmatically mount and unmount a component, you can now pass an `outro: true` option to `unmount` to play transitions before it is removed from the DOM.
 
-## Day 16
+- [docs](/docs/svelte/imperative-component-api#unmount)
+- [demo](/playground/a4ca332691204ccd887ec7b1df818182?version=5.13.0)
 
-Coming soon!
+## Day 15: debugging superpowers
 
-## Day 17
+The new `$inspect.trace(...)` rune gives you detailed information about which state changes caused a derived or effect to re-run.
 
-Coming soon!
+- [docs](</docs/svelte/$inspect#$inspect.trace()>)
+- [demo](/playground/d135c6f00beb4fa391725e59d8061604?version=5.14.0)
+
+## Day 16: `$app/state`
+
+SvelteKit's `$app/stores` module, which gives you a way to access information about (for example) the current page, now has a modern Svelte 5 state-based counterpart: `$app/state`. It exposes all the same information, but using fine-grained state, and without the clunky `$` prefix. `$app/stores` is now deprecated, and will be removed in SvelteKit 3 next year.
+
+You can migrate automatically by running the following command in your SvelteKit app:
+
+```bash
+npx sv migrate app-state
+```
+
+- [docs](/docs/kit/$app-state)
+- [tutorial](/tutorial/kit/page-state)
+
+## Day 17: better IntelliSense
+
+The parser used by the language tools that power things like the [Svelte for VS Code](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode) extension is the same one used by the Svelte compiler. Until today, it would fail if it encountered a syntax error, making it hard to provide things like autocomplete while you were in the middle of writing code.
+
+We just fixed that. Install the latest version of Svelte in your project, make sure your extensions are up to date, and feel the wind in your hair as you write your components.
+
+- [demo video](https://bsky.app/profile/svelte.dev/post/3ldjajjbkwc2n)
 
 ## Day 18
 

apps/svelte.dev/content/docs/cli/20-commands/20-sv-add.md

@@ -29,6 +29,7 @@ You can select multiple space-separated add-ons from [the list below](#Official-
 
 - `drizzle`
 - `eslint`
+- `sveltekit-adapter`
 - `lucia`
 - `mdsvex`
 - `paraglide`

apps/svelte.dev/content/docs/cli/20-commands/40-sv-migrate.md

@@ -15,10 +15,18 @@ npx sv migrate [migration]
 
 ## Migrations
 
+### `app-state`
+
+Migrates `$app/store` usage to `$app/state` in `.svelte` files. See the [migration guide](/docs/kit/migrating-to-sveltekit-2#SvelteKit-2.12:-$app-stores-deprecated) for more details.
+
 ### `svelte-5`
 
 Upgrades a Svelte 4 app to use Svelte 5, and updates individual components to use [runes](../svelte/what-are-runes) and other Svelte 5 syntax ([see migration guide](../svelte/v5-migration-guide)).
 
+### `self-closing-tags`
+
+Replaces all the self-closing non-void elements in your `.svelte` files. See the [pull request](https://github.com/sveltejs/kit/pull/12128) for more details.
+
 ### `svelte-4`
 
 Upgrades a Svelte 3 app to use Svelte 4 ([see migration guide](../svelte/v4-migration-guide)).

apps/svelte.dev/content/docs/kit/10-getting-started/40-web-standards.md

@@ -79,7 +79,7 @@ Most of the time, your endpoints will return complete data, as in the `userAgent
 
 ## URL APIs
 
-URLs are represented by the [`URL`](https://developer.mozilla.org/en-US/docs/Web/API/URL) interface, which includes useful properties like `origin` and `pathname` (and, in the browser, `hash`). This interface shows up in various places — `event.url` in [hooks](hooks) and [server routes](routing#server), [`$page.url`]($app-stores) in [pages](routing#page), `from` and `to` in [`beforeNavigate` and `afterNavigate`]($app-navigation) and so on.
+URLs are represented by the [`URL`](https://developer.mozilla.org/en-US/docs/Web/API/URL) interface, which includes useful properties like `origin` and `pathname` (and, in the browser, `hash`). This interface shows up in various places — `event.url` in [hooks](hooks) and [server routes](routing#server), [`page.url`]($app-state) in [pages](routing#page), `from` and `to` in [`beforeNavigate` and `afterNavigate`]($app-navigation) and so on.
 
 ### URLSearchParams
 

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

@@ -133,12 +133,15 @@ If an error occurs during `load`, SvelteKit will render a default error page. Yo
 ```svelte
 <!--- file: src/routes/blog/[slug]/+error.svelte --->
 <script>
-	import { page } from '$app/stores';
+	import { page } from '$app/state';
 </script>
 
-<h1>{$page.status}: {$page.error.message}</h1>
+<h1>{page.status}: {page.error.message}</h1>
 ```
 
+> [!LEGACY]
+> `$app/state` was added in SvelteKit 2.12. If you're using an earlier version or are using Svelte 4, use `$app/stores` instead.
+
 SvelteKit will 'walk up the tree' looking for the closest error boundary — if the file above didn't exist it would try `src/routes/blog/+error.svelte` and then `src/routes/+error.svelte` before rendering the default error page. If _that_ fails (or if the error was thrown from the `load` function of the root `+layout`, which sits 'above' the root `+error`), SvelteKit will bail out and render a static fallback error page, which you can customise by creating a `src/error.html` file.
 
 If the error occurs inside a `load` function in `+layout(.server).js`, the closest error boundary in the tree is an `+error.svelte` file _above_ that layout (not next to it).

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

@@ -117,14 +117,14 @@ Data returned from layout `load` functions is available to child `+layout.svelte
 ```svelte
 /// file: src/routes/blog/[slug]/+page.svelte
 <script>
-	+++import { page } from '$app/stores';+++
+	+++import { page } from '$app/state';+++
 
 	/** @type {{ data: import('./$types').PageData }} */
 	let { data } = $props();
 
 +++	// we can access `data.posts` because it's returned from
 	// the parent layout `load` function
-	let index = $derived(data.posts.findIndex(post => post.slug === $page.params.slug));
+	let index = $derived(data.posts.findIndex(post => post.slug === page.params.slug));
 	let next = $derived(data.posts[index + 1]);+++
 </script>
 
@@ -138,24 +138,28 @@ Data returned from layout `load` functions is available to child `+layout.svelte
 
 > [!NOTE] If multiple `load` functions return data with the same key, the last one 'wins' — the result of a layout `load` returning `{ a: 1, b: 2 }` and a page `load` returning `{ b: 3, c: 4 }` would be `{ a: 1, b: 3, c: 4 }`.
 
-## $page.data
+## page.data
 
 The `+page.svelte` component, and each `+layout.svelte` component above it, has access to its own data plus all the data from its parents.
 
-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`:
+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 --->
 <script>
-	import { page } from '$app/stores';
+	import { page } from '$app/state';
 </script>
 
 <svelte:head>
-	<title>{$page.data.title}</title>
+	<title>{page.data.title}</title>
 </svelte:head>
 ```
 
-Type information for `$page.data` is provided by `App.PageData`.
+Type information for `page.data` is provided by `App.PageData`.
+
+> [!LEGACY]
+> `$app/state` was added in SvelteKit 2.12. If you're using an earlier version or are using Svelte 4, use `$app/stores` instead.
+> It provides a `page` store with the same interface that you can subscribe to, e.g. `$page.data.title`.
 
 ## Universal vs server
 

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

@@ -103,7 +103,7 @@ As well as the `action` attribute, we can use the `formaction` attribute on a bu
 
 ## Anatomy of an action
 
-Each action receives a `RequestEvent` object, allowing you to read the data with `request.formData()`. After processing the request (for example, logging the user in by setting a cookie), the action can respond with data that will be available through the `form` property on the corresponding page and through `$page.form` app-wide until the next update.
+Each action receives a `RequestEvent` object, allowing you to read the data with `request.formData()`. After processing the request (for example, logging the user in by setting a cookie), the action can respond with data that will be available through the `form` property on the corresponding page and through `page.form` app-wide until the next update.
 
 ```js
 /// file: src/routes/login/+page.server.js
@@ -157,7 +157,7 @@ export const actions = {
 
 ### Validation errors
 
-If the request couldn't be processed because of invalid data, you can return validation errors — along with the previously submitted form values — back to the user so that they can try again. The `fail` function lets you return an HTTP status code (typically 400 or 422, in the case of validation errors) along with the data. The status code is available through `$page.status` and the data through `form`:
+If the request couldn't be processed because of invalid data, you can return validation errors — along with the previously submitted form values — back to the user so that they can try again. The `fail` function lets you return an HTTP status code (typically 400 or 422, in the case of validation errors) along with the data. The status code is available through `page.status` and the data through `form`:
 
 ```js
 /// file: src/routes/login/+page.server.js
@@ -353,7 +353,7 @@ The easiest way to progressively enhance a form is to add the `use:enhance` acti
 
 Without an argument, `use:enhance` will emulate the browser-native behaviour, just without the full-page reloads. It will:
 
-- update the `form` property, `$page.form` and `$page.status` on a successful or invalid response, but only if the action is on the same page you're submitting from. For example, if your form looks like `<form action="/somewhere/else" ..>`, `form` and `$page` will _not_ be updated. This is because in the native form submission case you would be redirected to the page the action is on. If you want to have them updated either way, use [`applyAction`](#Progressive-enhancement-Customising-use:enhance)
+- update the `form` property, `page.form` and `page.status` on a successful or invalid response, but only if the action is on the same page you're submitting from. For example, if your form looks like `<form action="/somewhere/else" ..>`, the `form` prop and the `page.form` state will _not_ be updated. This is because in the native form submission case you would be redirected to the page the action is on. If you want to have them updated either way, use [`applyAction`](#Progressive-enhancement-Customising-use:enhance)
 - reset the `<form>` element
 - invalidate all data using `invalidateAll` on a successful response
 - call `goto` on a redirect response
@@ -412,7 +412,7 @@ If you return a callback, you may need to reproduce part of the default `use:enh
 
 The behaviour of `applyAction(result)` depends on `result.type`:
 
-- `success`, `failure` — sets `$page.status` to `result.status` and updates `form` and `$page.form` to `result.data` (regardless of where you are submitting from, in contrast to `update` from `enhance`)
+- `success`, `failure` — sets `page.status` to `result.status` and updates `form` and `page.form` to `result.data` (regardless of where you are submitting from, in contrast to `update` from `enhance`)
 - `redirect` — calls `goto(result.location, { invalidateAll: true })`
 - `error` — renders the nearest `+error` boundary with `result.error`
 
@@ -431,8 +431,9 @@ We can also implement progressive enhancement ourselves, without `use:enhance`,
 	/** @type {{ form: import('./$types').ActionData }} */
 	let { form } = $props();
 
-	/** @param {{ currentTarget: EventTarget & HTMLFormElement}} event */
+	/** @param {SubmitEvent & { currentTarget: EventTarget & HTMLFormElement}} event */
 	async function handleSubmit(event) {
+		event.preventDefault();
 		const data = new FormData(event.currentTarget);
 
 		const response = await fetch(event.currentTarget.action, {
@@ -452,7 +453,7 @@ We can also implement progressive enhancement ourselves, without `use:enhance`,
 	}
 </script>
 
-<form method="POST" onsubmit|preventDefault={handleSubmit}>
+<form method="POST" onsubmit={handleSubmit}>
 	<!-- content -->
 </form>
 ```

apps/svelte.dev/content/docs/kit/20-core-concepts/50-state-management.md

@@ -41,7 +41,7 @@ Instead, you should _authenticate_ the user using [`cookies`](load#Cookies) and
 
 ## No side-effects in load
 
-For the same reason, your `load` functions should be _pure_ — no side-effects (except maybe the occasional `console.log(...)`). For example, you might be tempted to write to a store inside a `load` function so that you can use the store value in your components:
+For the same reason, your `load` functions should be _pure_ — no side-effects (except maybe the occasional `console.log(...)`). For example, you might be tempted to write to a store or global state inside a `load` function so that you can use the value in your components:
 
 ```js
 /// file: +page.js
@@ -77,31 +77,25 @@ export async function load({ fetch }) {
 }
 ```
 
-...and pass it around to the components that need it, or use [`$page.data`](load#$page.data).
+...and pass it around to the components that need it, or use [`page.data`](load#page.data).
 
 If you're not using SSR, then there's no risk of accidentally exposing one user's data to another. But you should still avoid side-effects in your `load` functions — your application will be much easier to reason about without them.
 
-## Using stores with context
+## Using state and stores with context
 
-You might wonder how we're able to use `$page.data` and other [app stores]($app-stores) if we can't use our own stores. The answer is that app stores on the server use Svelte's [context API](/tutorial/svelte/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:
+You might wonder how we're able to use `page.data` and other [app state]($app-state) (or [app stores]($app-stores)) if we can't use global state. The answer is that app state and app stores on the server use Svelte's [context API](/tutorial/svelte/context-api) — the state (or 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 state:
 
 ```svelte
 <!--- file: src/routes/+layout.svelte --->
 <script>
 	import { setContext } from 'svelte';
-	import { writable } from 'svelte/store';
 
 	/** @type {{ data: import('./$types').LayoutData }} */
 	let { data } = $props();
 
-	// Create a store and update it when necessary...
-	const user = writable(data.user);
-	$effect.pre(() => {
-		user.set(data.user);
-	});
-
-	// ...and add it to the context for child components to access
-	setContext('user', user);
+	// Pass a function referencing our state
+	// to the context for child components to access
+	setContext('user', () => data.user);
 </script>
 ```
 
@@ -114,10 +108,15 @@ You might wonder how we're able to use `$page.data` and other [app stores]($app-
 	const user = getContext('user');
 </script>
 
-<p>Welcome {$user.name}</p>
+<p>Welcome {user().name}</p>
 ```
 
-Updating the value of a context-based store in deeper-level pages or components while the page is being rendered via SSR will not affect the value in the parent component because it has already been rendered by the time the store value is updated. In contrast, on the client (when CSR is enabled, which is the default) the value will be propagated and components, pages, and layouts higher in the hierarchy will react to the new value. Therefore, to avoid values 'flashing' during state updates during hydration, it is generally recommended to pass state down into components rather than up.
+> [!NOTE] We're passing a function into `setContext` to keep reactivity across boundaries. Read more about it [here](https://svelte.dev/docs/svelte/$state#Passing-state-into-functions)
+
+> [!LEGACY]
+> You also use stores from `svelte/store` for this, but when using Svelte 5 it is recommended to make use of universal reactivity instead.
+
+Updating the value of context-based state in deeper-level pages or components while the page is being rendered via SSR will not affect the value in the parent component because it has already been rendered by the time the state value is updated. In contrast, on the client (when CSR is enabled, which is the default) the value will be propagated and components, pages, and layouts higher in the hierarchy will react to the new value. Therefore, to avoid values 'flashing' during state updates during hydration, it is generally recommended to pass state down into components rather than up.
 
 If you're not using SSR (and can guarantee that you won't need to use SSR in future) then you can safely keep state in a shared module, without using the context API.
 
@@ -154,7 +153,7 @@ Instead, we need to make the value [_reactive_](/tutorial/svelte/state):
 	/** @type {{ data: import('./$types').PageData }} */
 	let { data } = $props();
 
-+++	let wordCount = $state(data.content.split(' ').length);
++++	let wordCount = $derived(data.content.split(' ').length);
 	let estimatedReadingTime = $derived(wordCount / 250);+++
 </script>
 ```
@@ -164,14 +163,18 @@ Instead, we need to make the value [_reactive_](/tutorial/svelte/state):
 Reusing components like this means that things like sidebar scroll state are preserved, and you can easily animate between changing values. In the case that you do need to completely destroy and remount a component on navigation, you can use this pattern:
 
 ```svelte
-{#key $page.url.pathname}
+<script>
+	import { page } from '$app/state';
+</script>
+
+{#key page.url.pathname}
 	<BlogPost title={data.title} content={data.title} />
 {/key}
 ```
 
 ## Storing state in the URL
 
-If you have state that should survive a reload and/or affect SSR, such as filters or sorting rules on a table, URL search parameters (like `?sort=price&order=ascending`) are a good place to put them. You can put them in `<a href="...">` or `<form action="...">` attributes, or set them programmatically via `goto('?key=value')`. They can be accessed inside `load` functions via the `url` parameter, and inside components via `$page.url.searchParams`.
+If you have state that should survive a reload and/or affect SSR, such as filters or sorting rules on a table, URL search parameters (like `?sort=price&order=ascending`) are a good place to put them. You can put them in `<a href="...">` or `<form action="...">` attributes, or set them programmatically via `goto('?key=value')`. They can be accessed inside `load` functions via the `url` parameter, and inside components via `page.url.searchParams`.
 
 ## Storing ephemeral state in snapshots