From dc3d3338de8c29c740a5c581a9f3d16c6213e623 Mon Sep 17 00:00:00 2001
From: Simon Holthausen <simon.holthausen@vercel.com>
Date: Mon, 28 Oct 2024 10:29:36 +0100
Subject: [PATCH 1/2] docs: sync repos

---
 .../docs/kit/20-core-concepts/10-routing.md   | 45 ++++++++++++-------
 .../docs/kit/20-core-concepts/20-load.md      | 35 ++++++++-------
 .../kit/20-core-concepts/30-form-actions.md   | 25 +++++------
 .../20-core-concepts/50-state-management.md   | 18 ++++----
 .../25-build-and-deploy/90-adapter-vercel.md  |  4 +-
 .../kit/30-advanced/10-advanced-routing.md    |  6 +--
 .../content/docs/kit/30-advanced/20-hooks.md  |  6 ++-
 .../docs/kit/30-advanced/65-snapshots.md      |  2 +-
 .../kit/30-advanced/67-shallow-routing.md     |  2 +-
 .../docs/kit/40-best-practices/03-auth.md     | 23 ++++++++++
 .../kit/40-best-practices/05-performance.md   |  2 +-
 .../docs/kit/98-reference/10-@sveltejs-kit.md |  6 +--
 .../content/docs/kit/98-reference/26-$lib.md  | 16 ++++++-
 .../content/docs/kit/98-reference/54-types.md |  2 +-
 .../svelte/01-introduction/03-svelte-files.md |  2 +
 .../docs/svelte/02-runes/03-$derived.md       |  2 +
 .../docs/svelte/02-runes/04-$effect.md        |  2 +-
 .../docs/svelte/03-template-syntax/12-use.md  |  2 +-
 .../docs/svelte/06-runtime/02-context.md      |  4 +-
 .../svelte/06-runtime/03-lifecycle-hooks.md   |  9 ++--
 .../svelte/07-misc/07-v5-migration-guide.md   | 18 ++++----
 .../docs/svelte/98-reference/20-svelte.md     |  8 ++--
 .../svelte/98-reference/21-svelte-action.md   |  2 +-
 23 files changed, 152 insertions(+), 89 deletions(-)
 create mode 100644 apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md

diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md
index 0c48a2b2c2..66d2af54bb 100644
--- a/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md
+++ b/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md
@@ -37,17 +37,22 @@ A `+page.svelte` component defines a page of your app. By default, pages are ren
 <a href="/">Home</a>
 ```
 
+Pages can receive data from `load` functions via the `data` prop.
+
 ```svelte
 <!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 </script>
 
 <h1>{data.title}</h1>
 <div>{@html data.content}</div>
 ```
 
+> [!LEGACY] In Svelte 4
+> In Svelte 4, you'd use `export let data` instead
+
 > [!NOTE] Note that SvelteKit uses `<a>` elements to navigate between routes, rather than a framework-specific `<Link>` component.
 
 ### +page.js
@@ -153,21 +158,29 @@ But in many apps, there are elements that should be visible on _every_ page, suc
 
 To create a layout that applies to every page, make a file called `src/routes/+layout.svelte`. The default layout (the one that SvelteKit uses if you don't bring your own) looks like this...
 
-```html
-<slot></slot>
+```svelte
+<script>
+	let { children } = $props();
+</script>
+
+{@render children()}
 ```
 
-...but we can add whatever markup, styles and behaviour we want. The only requirement is that the component includes a `<slot>` for the page content. For example, let's add a nav bar:
+...but we can add whatever markup, styles and behaviour we want. The only requirement is that the component includes a `@render` tag for the page content. For example, let's add a nav bar:
+
+```svelte
+<!---- file: src/routes/+layout.svelte --->
+<script>
+	let { children } = $props();
+</script>
 
-```html
-/// file: src/routes/+layout.svelte
 <nav>
 	<a href="/">Home</a>
 	<a href="/about">About</a>
 	<a href="/settings">Settings</a>
 </nav>
 
-<slot></slot>
+{@render children()}
 ```
 
 If we create pages for `/`, `/about` and `/settings`...
@@ -196,8 +209,8 @@ We can create a layout that only applies to pages below `/settings` (while inher
 ```svelte
 <!--- file: src/routes/settings/+layout.svelte --->
 <script>
-	/** @type {import('./$types').LayoutData} */
-	export let data;
+	/** @type {{ data: import('./$types').LayoutData, children: import('svelte').Snippet }} */
+	let { data, children } = $props();
 </script>
 
 <h1>Settings</h1>
@@ -208,7 +221,7 @@ We can create a layout that only applies to pages below `/settings` (while inher
 	{/each}
 </div>
 
-<slot></slot>
+{@render children()}
 ```
 
 You can see how `data` is populated by looking at the `+layout.js` example in the next section just below.
@@ -239,8 +252,8 @@ Data returned from a layout's `load` function is also available to all its child
 ```svelte
 <!--- file: src/routes/settings/profile/+page.svelte --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 
 	console.log(data.sections); // [{ slug: 'profile', title: 'Profile' }, ...]
 </script>
@@ -370,13 +383,13 @@ export async function fallback({ request }) {
 
 Throughout the examples above, we've been importing types from a `$types.d.ts` file. This is a file SvelteKit creates for you in a hidden directory if you're using TypeScript (or JavaScript with JSDoc type annotations) to give you type safety when working with your root files.
 
-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`:
+For example, annotating `let { data } = $props()` 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 --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 </script>
 ```
 
diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md
index 3e50259a33..9de2b83ead 100644
--- a/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md
+++ b/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md
@@ -24,14 +24,17 @@ export function load({ params }) {
 ```svelte
 <!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 </script>
 
 <h1>{data.post.title}</h1>
 <div>{@html data.post.content}</div>
 ```
 
+> [!LEGACY] In Svelte 4
+> In Svelte 4, you'd use `export let data` instead
+
 Thanks to the generated `$types` module, we get full type safety.
 
 A `load` function in a `+page.js` file runs both on the server and in the browser (unless combined with `export const ssr = false`, in which case it will [only run in the browser](page-options#ssr)). If your `load` function should _always_ run on the server (because it uses private environment variables, for example, or accesses a database) then it would go in a `+page.server.js` instead.
@@ -85,13 +88,13 @@ export async function load() {
 ```svelte
 <!--- file: src/routes/blog/[slug]/+layout.svelte --->
 <script>
-	/** @type {import('./$types').LayoutData} */
-	export let data;
+	/** @type {{ data: import('./$types').LayoutData, children: Snippet }} */
+	let { data, children } = $props();
 </script>
 
 <main>
-	<!-- +page.svelte is rendered in this <slot> -->
-	<slot />
+	<!-- +page.svelte is `@render`ed here -->
+	{@render children()}
 </main>
 
 <aside>
@@ -115,13 +118,13 @@ Data returned from layout `load` functions is available to child `+layout.svelte
 <script>
 	+++import { page } from '$app/stores';+++
 
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @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 next = $derived(data.posts[index - 1];)+++
+	let next = $derived(data.posts[index + 1]);+++
 </script>
 
 <h1>{data.post.title}</h1>
@@ -330,7 +333,7 @@ export async function load({ fetch, setHeaders }) {
 }
 ```
 
-Setting the same header multiple times (even in separate `load` functions) is an error — you can only set a given header once. You cannot add a `set-cookie` header with `setHeaders` — use `cookies.set(name, value, options)` instead.
+Setting the same header multiple times (even in separate `load` functions) is an error. You can only set a given header once using the `setHeaders` function. You cannot add a `set-cookie` header with `setHeaders` — use `cookies.set(name, value, options)` instead.
 
 ## Using parent data
 
@@ -365,8 +368,8 @@ export async function load({ parent }) {
 ```svelte
 <!--- file: src/routes/abc/+page.svelte --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 </script>
 
 <!-- renders `1 + 2 = 3` -->
@@ -504,8 +507,8 @@ This is useful for creating skeleton loading states, for example:
 ```svelte
 <!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 </script>
 
 <h1>{data.post.title}</h1>
@@ -645,8 +648,8 @@ export async function load({ fetch, depends }) {
 <script>
 	import { invalidate, invalidateAll } from '$app/navigation';
 
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 
 	function rerunLoadFunction() {
 		// any of these will cause the `load` function to rerun
diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md
index deb4ef73ab..5d8c439f86 100644
--- a/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md
+++ b/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md
@@ -140,11 +140,8 @@ export const actions = {
 ```svelte
 <!--- file: src/routes/login/+page.svelte --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
-
-	/** @type {import('./$types').ActionData} */
-	export let form;
+	/** @type {{ data: import('./$types').PageData, form: import('./$types').ActionData }} */
+	let { data, form } = $props();
 </script>
 
 {#if form?.success}
@@ -154,6 +151,9 @@ export const actions = {
 {/if}
 ```
 
+> [!LEGACY] In Svelte 4
+> In Svelte 4, you'd use `export let data` and `export let form` instead to declare properties
+
 ### 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`:
@@ -339,8 +339,8 @@ The easiest way to progressively enhance a form is to add the `use:enhance` acti
 <script>
 	+++import { enhance } from '$app/forms';+++
 
-	/** @type {import('./$types').ActionData} */
-	export let form;
+	/** @type {{ form: import('./$types').ActionData }} */
+	let { form } = $props();
 </script>
 
 <form method="POST" +++use:enhance+++>
@@ -390,8 +390,8 @@ If you return a callback, you may need to reproduce part of the default `use:enh
 <script>
 	import { enhance, +++applyAction+++ } from '$app/forms';
 
-	/** @type {import('./$types').ActionData} */
-	export let form;
+	/** @type {{ form: import('./$types').ActionData }} */
+	let { form } = $props();
 </script>
 
 <form
@@ -427,11 +427,8 @@ We can also implement progressive enhancement ourselves, without `use:enhance`,
 	import { invalidateAll, goto } from '$app/navigation';
 	import { applyAction, deserialize } from '$app/forms';
 
-	/** @type {import('./$types').ActionData} */
-	export let form;
-
-	/** @type {any} */
-	let error;
+	/** @type {{ form: import('./$types').ActionData }} */
+	let { form } = $props();
 
 	/** @param {{ currentTarget: EventTarget & HTMLFormElement}} event */
 	async function handleSubmit(event) {
diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/50-state-management.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/50-state-management.md
index f993f59ca6..be74d59535 100644
--- a/apps/svelte.dev/content/docs/kit/20-core-concepts/50-state-management.md
+++ b/apps/svelte.dev/content/docs/kit/20-core-concepts/50-state-management.md
@@ -90,12 +90,14 @@ You might wonder how we're able to use `$page.data` and other [app stores]($app-
 	import { setContext } from 'svelte';
 	import { writable } from 'svelte/store';
 
-	/** @type {import('./$types').LayoutData} */
-	export let data;
+	/** @type {{ data: import('./$types').LayoutData }} */
+	let { data } = $props();
 
 	// Create a store and update it when necessary...
-	const user = writable();
-	$: user.set(data.user);
+	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);
@@ -125,8 +127,8 @@ When you navigate around your application, SvelteKit reuses existing layout and
 ```svelte
 <!--- file: src/routes/blog/[slug]/+page.svelte --->
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 
 	// THIS CODE IS BUGGY!
 	const wordCount = data.content.split(' ').length;
@@ -148,8 +150,8 @@ Instead, we need to make the value [_reactive_](/tutorial/svelte/state):
 ```svelte
 /// file: src/routes/blog/[slug]/+page.svelte
 <script>
-	/** @type {import('./$types').PageData} */
-	export let data;
+	/** @type {{ data: import('./$types').PageData }} */
+	let { data } = $props();
 
 +++	let wordCount = $state(data.content.split(' ').length);
 	let estimatedReadingTime = $derived(wordCount / 250);+++
diff --git a/apps/svelte.dev/content/docs/kit/25-build-and-deploy/90-adapter-vercel.md b/apps/svelte.dev/content/docs/kit/25-build-and-deploy/90-adapter-vercel.md
index 226d8cb6ca..57867ce7c9 100644
--- a/apps/svelte.dev/content/docs/kit/25-build-and-deploy/90-adapter-vercel.md
+++ b/apps/svelte.dev/content/docs/kit/25-build-and-deploy/90-adapter-vercel.md
@@ -140,8 +140,8 @@ export function load() {
 ```svelte
 <!--- file: +layout.svelte --->
 <script>
-	/** @type {import('./$types').LayoutServerData} */
-	export let data;
+	/** @type {{ data: import('./$types').LayoutServerData }} */
+	let { data } = $props();
 </script>
 
 <p>This staging environment was deployed from {data.deploymentGitBranch}.</p>
diff --git a/apps/svelte.dev/content/docs/kit/30-advanced/10-advanced-routing.md b/apps/svelte.dev/content/docs/kit/30-advanced/10-advanced-routing.md
index 26b1be2143..06122648f1 100644
--- a/apps/svelte.dev/content/docs/kit/30-advanced/10-advanced-routing.md
+++ b/apps/svelte.dev/content/docs/kit/30-advanced/10-advanced-routing.md
@@ -193,7 +193,7 @@ You can also put a `+page` directly inside a `(group)`, for example if `/` shoul
 
 ### Breaking out of layouts
 
-The root layout applies to every page of your app — if omitted, it defaults to `<slot />`. If you want some pages to have a different layout hierarchy than the rest, then you can put your entire app inside one or more groups _except_ the routes that should not inherit the common layouts.
+The root layout applies to every page of your app — if omitted, it defaults to `{@render children()}`. If you want some pages to have a different layout hierarchy than the rest, then you can put your entire app inside one or more groups _except_ the routes that should not inherit the common layouts.
 
 In the example above, the `/admin` route does not inherit either the `(app)` or `(marketing)` layouts.
 
@@ -260,11 +260,11 @@ Not all use cases are suited for layout grouping, nor should you feel compelled
 <!--- file: src/routes/nested/route/+layout@.svelte --->
 <script>
 	import ReusableLayout from '$lib/ReusableLayout.svelte';
-	export let data;
+	let { data, children } = $props();
 </script>
 
 <ReusableLayout {data}>
-	<slot />
+	{@render children()}
 </ReusableLayout>
 ```
 
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
index 74d4c815d8..6decc1cbf4 100644
--- a/apps/svelte.dev/content/docs/kit/30-advanced/20-hooks.md
+++ b/apps/svelte.dev/content/docs/kit/30-advanced/20-hooks.md
@@ -37,7 +37,11 @@ export async function handle({ event, resolve }) {
 
 > [!NOTE] Requests for static assets — which includes pages that were already prerendered — are _not_ handled by SvelteKit.
 
-If unimplemented, defaults to `({ event, resolve }) => resolve(event)`. To add custom data to the request, which is passed to handlers in `+server.js` and server `load` functions, populate the `event.locals` object, as shown below.
+If unimplemented, defaults to `({ event, resolve }) => resolve(event)`.
+
+### locals
+
+To add custom data to the request, which is passed to handlers in `+server.js` and server `load` functions, populate the `event.locals` object, as shown below.
 
 ```js
 /// file: src/hooks.server.js
diff --git a/apps/svelte.dev/content/docs/kit/30-advanced/65-snapshots.md b/apps/svelte.dev/content/docs/kit/30-advanced/65-snapshots.md
index 5a55330f0d..cc7477f0fe 100644
--- a/apps/svelte.dev/content/docs/kit/30-advanced/65-snapshots.md
+++ b/apps/svelte.dev/content/docs/kit/30-advanced/65-snapshots.md
@@ -11,7 +11,7 @@ To do this, export a `snapshot` object with `capture` and `restore` methods from
 ```svelte
 <!--- file: +page.svelte --->
 <script>
-	let comment = '';
+	let comment = $state('');
 
 	/** @type {import('./$types').Snapshot<string>} */
 	export const snapshot = {
diff --git a/apps/svelte.dev/content/docs/kit/30-advanced/67-shallow-routing.md b/apps/svelte.dev/content/docs/kit/30-advanced/67-shallow-routing.md
index f4f871cf8e..f10edd0ad5 100644
--- a/apps/svelte.dev/content/docs/kit/30-advanced/67-shallow-routing.md
+++ b/apps/svelte.dev/content/docs/kit/30-advanced/67-shallow-routing.md
@@ -51,7 +51,7 @@ For this to work, you need to load the data that the `+page.svelte` expects. A c
 	import Modal from './Modal.svelte';
 	import PhotoPage from './[id]/+page.svelte';
 
-	export let data;
+	let { data } = $props();
 </script>
 
 {#each data.thumbnails as thumbnail}
diff --git a/apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md b/apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md
new file mode 100644
index 0000000000..e9ca338478
--- /dev/null
+++ b/apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md
@@ -0,0 +1,23 @@
+---
+title: Auth
+---
+
+Auth refers to authentication and authorization, which are common needs when building a web application. Authentication means verifying that the user is who they say they are based on their provided credentials. Authorization means determining which actions they are allowed to take.
+
+## Sessions vs tokens
+
+After the user has provided their credentials such as a username and password, we want to allow them to use the application without needing to provide their credentials again for future requests. Users are commonly authenticated on subsequent requests with either a session identifier or signed token such as a JSON Web Token (JWT).
+
+Session IDs are most commonly stored in a database. They can be immediately revoked, but require a database query to be made on each request.
+
+In contrast, JWT generally are not checked against a datastore, which means they cannot be immediately revoked. The advantage of this method is improved latency and reduced load on your datastore.
+
+## Integration points
+
+Auth [cookies](types#public-types-cookies) can be checked inside [server hooks](hooks#server-hooks). If a user is found matching the provided credentials, the user information can be stored in [`locals`](hooks#server-hooks-locals).
+
+## Guides
+
+[Lucia](https://lucia-next.pages.dev/) is a reference for session-based web app auth. It contains example code snippets and projects for implementing session-based auth within SvelteKit and other JS projects. You can add code which follows the Lucia guide to your project with `npx sv create` when creating a new project or `npx sv add lucia` for an existing project.
+
+An auth system is tightly coupled to a web framework because most of the code lies in validating user input, handling errors, and directing users to the appropriate next page. As a result, many of the generic JS auth libraries include one or more web frameworks within them. For this reason, many users will find it preferrable to follow a SvelteKit-specific guide such as the examples found in [Lucia](https://lucia-next.pages.dev/) rather than having multiple web frameworks inside their project.
diff --git a/apps/svelte.dev/content/docs/kit/40-best-practices/05-performance.md b/apps/svelte.dev/content/docs/kit/40-best-practices/05-performance.md
index 390236d9a2..2e358921dc 100644
--- a/apps/svelte.dev/content/docs/kit/40-best-practices/05-performance.md
+++ b/apps/svelte.dev/content/docs/kit/40-best-practices/05-performance.md
@@ -57,7 +57,7 @@ You can reduce the size of font files by [subsetting](https://web.dev/learn/perf
 
 ### Svelte version
 
-We recommend running the latest version of Svelte. Svelte 4 is smaller and faster than Svelte 3. (The [Svelte 5 preview](https://svelte-5-preview.vercel.app/) is much smaller and faster still, but we don't recommend that you upgrade to this version until it's production ready.)
+We recommend running the latest version of Svelte. Svelte 5 is smaller and faster than Svelte 4, which is smaller and faster than Svelte 3.
 
 ### Packages
 
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
index f690bfa242..863d719093 100644
--- 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
@@ -1260,7 +1260,7 @@ export async function load({ depends }) {
 <script>
 	import { invalidate } from '$app/navigation';
 
-	export let data;
+	let { data } = $props();
 
 	const increase = async () => {
 		await invalidate('increase:count');
@@ -1856,7 +1856,7 @@ locals: App.Locals;
 
 <div class="ts-block-property-details">
 
-Contains custom data that was added to the request within the [`handle hook`](https://svelte.dev/docs/kit/hooks#Server-hooks-handle).
+Contains custom data that was added to the request within the [`server handle hook`](https://svelte.dev/docs/kit/hooks#Server-hooks-handle).
 
 </div>
 </div>
@@ -2451,7 +2451,7 @@ export async function load({ depends }) {
 <script>
 	import { invalidate } from '$app/navigation';
 
-	export let data;
+	let { data } = $props();
 
 	const increase = async () => {
 		await invalidate('increase:count');
diff --git a/apps/svelte.dev/content/docs/kit/98-reference/26-$lib.md b/apps/svelte.dev/content/docs/kit/98-reference/26-$lib.md
index 2feb1a4402..d9262a2954 100644
--- a/apps/svelte.dev/content/docs/kit/98-reference/26-$lib.md
+++ b/apps/svelte.dev/content/docs/kit/98-reference/26-$lib.md
@@ -2,4 +2,18 @@
 title: $lib
 ---
 
-TODO
+SvelteKit automatically makes files under `src/lib` available using the `$lib` import alias. You can change which directory this alias points to in your [config file](configuration#files).
+
+```svelte
+<!--- file: src/lib/Component.svelte --->
+A reusable component
+```
+
+```svelte
+<!--- file: src/routes/+page.svelte --->
+<script>
+    import Component from '$lib/Component.svelte';
+</script>
+
+<Component />
+```
diff --git a/apps/svelte.dev/content/docs/kit/98-reference/54-types.md b/apps/svelte.dev/content/docs/kit/98-reference/54-types.md
index 13b51e7d08..7dc647734d 100644
--- a/apps/svelte.dev/content/docs/kit/98-reference/54-types.md
+++ b/apps/svelte.dev/content/docs/kit/98-reference/54-types.md
@@ -175,7 +175,7 @@ message: string;
 
 ## Locals
 
-The interface that defines `event.locals`, which can be accessed in [hooks](https://svelte.dev/docs/kit/hooks) (`handle`, and `handleError`), server-only `load` functions, and `+server.js` files.
+The interface that defines `event.locals`, which can be accessed in server [hooks](https://svelte.dev/docs/kit/hooks) (`handle`, and `handleError`), server-only `load` functions, and `+server.js` files.
 
 <div class="ts-block">
 
diff --git a/apps/svelte.dev/content/docs/svelte/01-introduction/03-svelte-files.md b/apps/svelte.dev/content/docs/svelte/01-introduction/03-svelte-files.md
index d4c223a7ec..a0c0bf5cc9 100644
--- a/apps/svelte.dev/content/docs/svelte/01-introduction/03-svelte-files.md
+++ b/apps/svelte.dev/content/docs/svelte/01-introduction/03-svelte-files.md
@@ -50,6 +50,8 @@ A `<script>` tag with a `module` attribute runs once when the module first evalu
 
 You can `export` bindings from this block, and they will become exports of the compiled module. You cannot `export default`, since the default export is the component itself.
 
+> [!NOTE] If you are using TypeScript and import such exports from a `module` block into a `.ts` file, make sure to have your editor setup so that TypeScript knows about them. This is the case for our VS Code extension and the IntelliJ plugin, in other cases you might need to setup our [TypeScript editor plugin](https://www.npmjs.com/package/typescript-svelte-plugin).
+
 > [!LEGACY]
 > In Svelte 4, this script tag was created using `<script context="module">`
 
diff --git a/apps/svelte.dev/content/docs/svelte/02-runes/03-$derived.md b/apps/svelte.dev/content/docs/svelte/02-runes/03-$derived.md
index 4f0d70dcc8..96cafeaaea 100644
--- a/apps/svelte.dev/content/docs/svelte/02-runes/03-$derived.md
+++ b/apps/svelte.dev/content/docs/svelte/02-runes/03-$derived.md
@@ -21,6 +21,8 @@ The expression inside `$derived(...)` should be free of side-effects. Svelte wil
 
 As with `$state`, you can mark class fields as `$derived`.
 
+> [!NOTE] Code in Svelte components is only executed once at creation, without the `$derived` rune `double` would maintain it's original value.
+
 ## `$derived.by`
 
 Sometimes you need to create complex derivations that don't fit inside a short expression. In these cases, you can use `$derived.by` which accepts a function as its argument.
diff --git a/apps/svelte.dev/content/docs/svelte/02-runes/04-$effect.md b/apps/svelte.dev/content/docs/svelte/02-runes/04-$effect.md
index eedca52d9d..07291daa43 100644
--- a/apps/svelte.dev/content/docs/svelte/02-runes/04-$effect.md
+++ b/apps/svelte.dev/content/docs/svelte/02-runes/04-$effect.md
@@ -179,7 +179,7 @@ Apart from the timing, `$effect.pre` works exactly like `$effect`.
 
 ## `$effect.tracking`
 
-The `$effect.tracking` rune is an advanced feature that tells you whether or not the code is running inside a tracking context, such as an effect or inside your template ([demo](/playground/untitled#H4sIAAAAAAAAE3XP0QrCMAwF0F-JRXAD595rLfgdzodRUyl0bVgzQcb-3VYFQfExl5tDMgvrPCYhT7MI_YBCiiOR2Aq-UxnSDT1jnlOcRlMSlczoiHUXOjYxpOhx5-O12rgAJg4UAwaGhDyR3Gxhjdai4V1v2N2wqus9tC3Y3ifMQjbehaqq4aBhLtEv_Or893icCsdLve-Caj8nBkU67zMO5HtGCfM3sKiWNKhV0zwVaBqd3x3ixVmHFyFLuJyXB-moOe8pAQAA)):
+The `$effect.tracking` rune is an advanced feature that tells you whether or not the code is running inside a tracking context, such as an effect or inside your template ([demo](/playground/untitled#H4sIAAAAAAAACn3PwYrCMBDG8VeZDYIt2PYeY8Dn2HrIhqkU08nQjItS-u6buAt7UDzmz8ePyaKGMWBS-nNRcmdU-hHUTpGbyuvI3KZvDFLal0v4qvtIgiSZUSb5eWSxPfWSc4oB2xDP1XYk8HHiSHkICeXKeruDDQ4Demlldv4y0rmq6z10HQwuJMxGVv4mVVXDwcJS0jP9u3knynwtoKz1vifT_Z9Jhm0WBCcOTlDD8kyspmML5qNpHg40jc3fFryJ0iWsp_UHgz3180oBAAA=)):
 
 ```svelte
 <script>
diff --git a/apps/svelte.dev/content/docs/svelte/03-template-syntax/12-use.md b/apps/svelte.dev/content/docs/svelte/03-template-syntax/12-use.md
index ff50e38cf2..f3db72a772 100644
--- a/apps/svelte.dev/content/docs/svelte/03-template-syntax/12-use.md
+++ b/apps/svelte.dev/content/docs/svelte/03-template-syntax/12-use.md
@@ -45,7 +45,7 @@ The action is only called once (but not during server-side rendering) — it wil
 
 ## Typing
 
-The `Action` interface receives three optional type arguments — a node type (which can be `Element`, if the action applies to everything), a parameter, and any custom event handlers created by the action.:
+The `Action` interface receives three optional type arguments — a node type (which can be `Element`, if the action applies to everything), a parameter, and any custom event handlers created by the action:
 
 ```svelte
 <!--- file: App.svelte --->
diff --git a/apps/svelte.dev/content/docs/svelte/06-runtime/02-context.md b/apps/svelte.dev/content/docs/svelte/06-runtime/02-context.md
index 87f254129e..62dd0c6a9e 100644
--- a/apps/svelte.dev/content/docs/svelte/06-runtime/02-context.md
+++ b/apps/svelte.dev/content/docs/svelte/06-runtime/02-context.md
@@ -80,9 +80,9 @@ Context is not inherently reactive. If you need reactive values in context then
 ```svelte
 <!--- file: Child.svelte --->
 <script>
-	import { setContext } from 'svelte';
+	import { getContext } from 'svelte';
 
-	const value = setContext('counter');
+	const value = getContext('counter');
 </script>
 
 <p>Count is {value.count}</p>
diff --git a/apps/svelte.dev/content/docs/svelte/06-runtime/03-lifecycle-hooks.md b/apps/svelte.dev/content/docs/svelte/06-runtime/03-lifecycle-hooks.md
index 2585290cfc..23a6629929 100644
--- a/apps/svelte.dev/content/docs/svelte/06-runtime/03-lifecycle-hooks.md
+++ b/apps/svelte.dev/content/docs/svelte/06-runtime/03-lifecycle-hooks.md
@@ -80,12 +80,13 @@ While there's no "after update" hook, you can use `tick` to ensure that the UI i
 
 ```svelte
 <script>
-	import { beforeUpdate, tick } from 'svelte';
+	import { tick } from 'svelte';
 
-	beforeUpdate(async () => {
+	$effect.pre(() => {
 		console.log('the component is about to update');
-		await tick();
-		console.log('the component just updated');
+		tick().then(
+				console.log('the component just updated');
+		);
 	});
 </script>
 ```
diff --git a/apps/svelte.dev/content/docs/svelte/07-misc/07-v5-migration-guide.md b/apps/svelte.dev/content/docs/svelte/07-misc/07-v5-migration-guide.md
index 3a47a9a799..1624755a6b 100644
--- a/apps/svelte.dev/content/docs/svelte/07-misc/07-v5-migration-guide.md
+++ b/apps/svelte.dev/content/docs/svelte/07-misc/07-v5-migration-guide.md
@@ -23,7 +23,7 @@ In Svelte 4, a `let` declaration at the top level of a component was implicitly
 Nothing else changes. `count` is still the number itself, and you read and write directly to it, without a wrapper like `.value` or `getCount()`.
 
 > [!DETAILS] Why we did this
-> `let` being implicitly reactive at the top level worked great, but it meant that reactivity was constrained - a `let` declaration anywhere else was not reactive. This forced you to resort to using stores when refactoring code out of the top level of components for reuse. This meant you had to learn an entirely separate reactivity model, and the result often wasn't as nice to work with. Because reactivity is more explicit in Svelte 5, you can keep using the same API in an outside the top level of components. Head to [the tutorial](/tutorial) to learn more.
+> `let` being implicitly reactive at the top level worked great, but it meant that reactivity was constrained - a `let` declaration anywhere else was not reactive. This forced you to resort to using stores when refactoring code out of the top level of components for reuse. This meant you had to learn an entirely separate reactivity model, and the result often wasn't as nice to work with. Because reactivity is more explicit in Svelte 5, you can keep using the same API outside the top level of components. Head to [the tutorial](/tutorial) to learn more.
 
 ### $: -> $derived/$effect
 
@@ -58,10 +58,10 @@ A `$:` statement could also be used to create side effects. In Svelte 5, this is
 >
 > - `$:` only updated directly before rendering, which meant you could read stale values in-between rerenders
 > - `$:` only ran once per tick, which meant that statements may run less often than you think
-> - `$:` dependencies were determined through static analysis of the dependencies. This worked in most cases, but could break in subtle ways during a refactoring where dependencies would be > for example moved into a function and no longer be visible as a result
-> - `$:` statements were also ordered by using static analysis of the dependencies. In some cases there could be ties and the ordering would be wrong as a result, needing manual > interventions. Ordering could also break while refactoring code and some dependencies no longer being visible as a result.
+> - `$:` dependencies were determined through static analysis of the dependencies. This worked in most cases, but could break in subtle ways during a refactoring where dependencies would be for example moved into a function and no longer be visible as a result
+> - `$:` statements were also ordered by using static analysis of the dependencies. In some cases there could be ties and the ordering would be wrong as a result, needing manual interventions. Ordering could also break while refactoring code and some dependencies no longer being visible as a result.
 >
-> Lastly, it wasn't TypeScript-friendly (our editor tooling had to jump through some hoops to make it valid for TypeScript), which was a blocker for making Svelte's reactivity model truly > universal.
+> Lastly, it wasn't TypeScript-friendly (our editor tooling had to jump through some hoops to make it valid for TypeScript), which was a blocker for making Svelte's reactivity model truly universal.
 >
 > `$derived` and `$effect` fix all of these by
 >
@@ -107,7 +107,7 @@ In Svelte 5, the `$props` rune makes this straightforward without any additional
 	export { klass as class};---
 	+++let { class: klass, ...rest } = $props();+++
 </script>
-<button {class} {...---$$restProps---+++rest+++}>click me</button>
+<button class={klass} {...---$$restProps---+++rest+++}>click me</button>
 ```
 
 > [!DETAILS] Why we did this
@@ -319,9 +319,9 @@ When spreading props, local event handlers must go _after_ the spread, or they r
 > - call said dispatch function with a string and possibly a payload
 > - retrieve said payload on the other end through a `.details` property, because the event itself was always a `CustomEvent`
 >
-> It was always possible to use component callback props, but because you had to listen to dom events using `on:`, it made sense to use `createEventDispatcher` for component events due to syntactical consistency. Now that we have event attributes (`onclick`), it's the other way around: Callback props are now the more sensible thing to do.
+> It was always possible to use component callback props, but because you had to listen to DOM events using `on:`, it made sense to use `createEventDispatcher` for component events due to syntactical consistency. Now that we have event attributes (`onclick`), it's the other way around: Callback props are now the more sensible thing to do.
 >
-> The removal of event modifiers is arguably one of the changes that seems like a step back for those who've liked the shorthand syntax of event modifiers. Given that they are not used that frequently, we traded a smaller surface area for more explicitness. Modifiers also were inconsistent, because most of them were only useable on Dom elements.
+> The removal of event modifiers is arguably one of the changes that seems like a step back for those who've liked the shorthand syntax of event modifiers. Given that they are not used that frequently, we traded a smaller surface area for more explicitness. Modifiers also were inconsistent, because most of them were only useable on DOM elements.
 >
 > Multiple listeners for the same event are also no longer possible, but it was something of an anti-pattern anyway, since it impedes readability: if there are many attributes, it becomes harder to spot that there are two handlers unless they are right next to each other. It also implies that the two handlers are independent, when in fact something like `event.stopImmediatePropagation()` inside `one` would prevent `two` from being called.
 >
@@ -429,7 +429,7 @@ In Svelte 4, you would pass data to a `<slot />` and then retrieve it with `let:
 > - the `let:` syntax was confusing to many people as it _creates_ a variable whereas all other `:` directives _receive_ a variable
 > - the scope of a variable declared with `let:` wasn't clear. In the example above, it may look like you can use the `item` slot prop in the `empty` slot, but that's not true
 > - named slots had to be applied to an element using the `slot` attribute. Sometimes you didn't want to create an element, so we had to add the `<svelte:fragment>` API
-> - named slots could also be applied to a component, which changed the semantics of where `let:` directives are available (even today us maintainers often don't know which way around it > works)
+> - named slots could also be applied to a component, which changed the semantics of where `let:` directives are available (even today us maintainers often don't know which way around it works)
 >
 > Snippets solve all of these problems by being much more readable and clear. At the same time they're more powerful as they allow you to define sections of UI that you can render _anywhere_, not just passing them as props to a component.
 
@@ -441,7 +441,7 @@ We thought the same, which is why we provide a migration script to do most of th
 
 - bump core dependencies in your `package.json`
 - migrate to runes (`let` -> `$state` etc)
-- migrate to event attributes for Dom elements (`on:click` -> `onclick`)
+- migrate to event attributes for DOM elements (`on:click` -> `onclick`)
 - migrate slot creations to render tags (`<slot />` -> `{@render children()}`)
 - migrate slot usages to snippets (`<div slot="x">...</div>` -> `{#snippet x()}<div>...</div>{/snippet}`)
 - migrate obvious component creations (`new Component(...)` -> `mount(Component, ...)`)
diff --git a/apps/svelte.dev/content/docs/svelte/98-reference/20-svelte.md b/apps/svelte.dev/content/docs/svelte/98-reference/20-svelte.md
index 6e4683ef4f..ca8b72774b 100644
--- a/apps/svelte.dev/content/docs/svelte/98-reference/20-svelte.md
+++ b/apps/svelte.dev/content/docs/svelte/98-reference/20-svelte.md
@@ -683,19 +683,21 @@ type MountOptions<
 	 */
 	target: Document | Element | ShadowRoot;
 	/**
-	 * Optional node inside `target` and when specified, it is used to render the component immediately before it.
+	 * Optional node inside `target`. When specified, it is used to render the component immediately before it.
 	 */
 	anchor?: Node;
 	/**
 	 * Allows the specification of events.
+	 * @deprecated Use callback props instead.
 	 */
 	events?: Record<string, (e: any) => any>;
 	/**
-	 * Used to define context at the component level.
+	 * Can be accessed via `getContext()` at the component level.
 	 */
 	context?: Map<any, any>;
 	/**
-	 * Used to control transition playback on initial render.  The default value is `true` to run transitions.
+	 * Whether or not to play transitions on initial render.
+	 * @default true
 	 */
 	intro?: boolean;
 } & ({} extends Props
diff --git a/apps/svelte.dev/content/docs/svelte/98-reference/21-svelte-action.md b/apps/svelte.dev/content/docs/svelte/98-reference/21-svelte-action.md
index 49f8b9f540..5ec1ccf3b4 100644
--- a/apps/svelte.dev/content/docs/svelte/98-reference/21-svelte-action.md
+++ b/apps/svelte.dev/content/docs/svelte/98-reference/21-svelte-action.md
@@ -13,7 +13,7 @@ export const myAction: Action<HTMLDivElement, { someProperty: boolean } | undefi
 	// ...
 }
 ```
-`Action<HTMLDivElement>` and `Action<HTMLDiveElement, undefined>` both signal that the action accepts no parameters.
+`Action<HTMLDivElement>` and `Action<HTMLDivElement, undefined>` both signal that the action accepts no parameters.
 
 You can return an object with methods `update` and `destroy` from the function and type which additional attributes and events it has.
 See interface `ActionReturn` for more details.

From 6ad8aa9a4eaa127d77618bc50d1e4e0de62a0aea Mon Sep 17 00:00:00 2001
From: Simon Holthausen <simon.holthausen@vercel.com>
Date: Mon, 28 Oct 2024 11:34:04 +0100
Subject: [PATCH 2/2] fix links

---
 apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md b/apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md
index e9ca338478..b2b8e07aa8 100644
--- a/apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md
+++ b/apps/svelte.dev/content/docs/kit/40-best-practices/03-auth.md
@@ -14,7 +14,7 @@ In contrast, JWT generally are not checked against a datastore, which means they
 
 ## Integration points
 
-Auth [cookies](types#public-types-cookies) can be checked inside [server hooks](hooks#server-hooks). If a user is found matching the provided credentials, the user information can be stored in [`locals`](hooks#server-hooks-locals).
+Auth [cookies](@sveltejs-kit#Cookies) can be checked inside [server hooks](hooks#Server-hooks). If a user is found matching the provided credentials, the user information can be stored in [`locals`](hooks#Server-hooks-handle).
 
 ## Guides