sveltejs
diff --git a/‎documentation/docs/00-introduction.md‎
Lines changed: 2 additions & 2 deletions b/‎documentation/docs/00-introduction.md‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎documentation/docs/01-routing.md‎
Lines changed: 9 additions & 9 deletions b/‎documentation/docs/01-routing.md‎
Lines changed: 9 additions & 9 deletions
diff --git a/‎documentation/docs/02-layouts.md‎
Lines changed: 3 additions & 3 deletions b/‎documentation/docs/02-layouts.md‎
Lines changed: 3 additions & 3 deletions
diff --git a/‎documentation/docs/03-loading.md‎
Lines changed: 7 additions & 7 deletions b/‎documentation/docs/03-loading.md‎
Lines changed: 7 additions & 7 deletions
diff --git a/‎documentation/docs/04-hooks.md‎
Lines changed: 6 additions & 6 deletions b/‎documentation/docs/04-hooks.md‎
Lines changed: 6 additions & 6 deletions
@@ -6,13 +6,13 @@ title: Introduction
 
 > SvelteKit is in early development, and some things may change before we hit version 1.0. This document is a work-in-progress. If you get stuck, reach out for help in the [Discord chatroom](https://svelte.dev/chat).
 >
-> See the [migration guides](/migrating) for help upgrading from Sapper.
+> See the [migration guides](/docs/migrating) for help upgrading from Sapper.
 
 ### What is SvelteKit?
 
 SvelteKit is a framework for building extremely high-performance web apps.
 
-Building an app with all the modern best practices is fiendishly complicated. Those practices include [build optimizations](https://vitejs.dev/guide/features.html#build-optimizations), so that you load only the minimal required code; [offline support](#service-workers); [prefetching](#anchor-options-sveltekit-prefetch) pages before the user initiates navigation; and [configurable rendering](#page-options) that allows you to generate HTML [on the server](#appendix-ssr) or [in the browser](#page-options-router) at runtime or [at build-time](#page-options-prerender). SvelteKit does all the boring stuff for you so that you can get on with the creative part.
+Building an app with all the modern best practices is fiendishly complicated. Those practices include [build optimizations](https://vitejs.dev/guide/features.html#build-optimizations), so that you load only the minimal required code; [offline support](/docs/service-workers); [prefetching](/docs/a-options#sveltekit-prefetch) pages before the user initiates navigation; and [configurable rendering](/docs/page-options) that allows you to generate HTML [on the server](/docs/appendix#ssr) or [in the browser](/docs/page-options#router) at runtime or [at build-time](/docs/page-options#prerender). SvelteKit does all the boring stuff for you so that you can get on with the creative part.
 
 It uses [Vite](https://vitejs.dev/) with a [Svelte plugin](https://github.com/sveltejs/vite-plugin-svelte) to provide a lightning-fast and feature-rich development experience with [Hot Module Replacement (HMR)](https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/config.md#hot), where changes to your code are reflected in the browser instantly.
 
 
@@ -4,17 +4,17 @@ title: Routing
 
 At the heart of SvelteKit is a _filesystem-based router_. This means that the structure of your application is defined by the structure of your codebase — specifically, the contents of `src/routes`.
 
-> You can change this to a different directory by editing the [project config](#configuration).
+> You can change this to a different directory by editing the [project config](/docs/configuration).
 
 There are two types of route — **pages** and **endpoints**.
 
 Pages typically generate HTML to display to the user (as well as any CSS and JavaScript needed for the page). By default, pages are rendered on both the client and server, though this behaviour is configurable.
 
-Endpoints run only on the server (or when you build your site, if [prerendering](#page-options-prerender)). This means it's the place to do things like access databases or APIs that require private credentials or return data that lives on a machine in your production network. Pages can request data from endpoints. Endpoints return JSON by default, though may also return data in other formats.
+Endpoints run only on the server (or when you build your site, if [prerendering](/docs/page-options#prerender)). This means it's the place to do things like access databases or APIs that require private credentials or return data that lives on a machine in your production network. Pages can request data from endpoints. Endpoints return JSON by default, though may also return data in other formats.
 
 ### Pages
 
-Pages are Svelte components written in `.svelte` files (or any file with an extension listed in [`config.extensions`](#configuration)). By default, when a user first visits the application, they will be served a server-rendered version of the page in question, plus some JavaScript that 'hydrates' the page and initialises a client-side router. From that point forward, navigating to other pages is handled entirely on the client for a fast, app-like feel where the common portions in the layout do not need to be rerendered.
+Pages are Svelte components written in `.svelte` files (or any file with an extension listed in [`config.extensions`](/docs/configuration)). By default, when a user first visits the application, they will be served a server-rendered version of the page in question, plus some JavaScript that 'hydrates' the page and initialises a client-side router. From that point forward, navigating to other pages is handled entirely on the client for a fast, app-like feel where the common portions in the layout do not need to be rerendered.
 
 The filename determines the route. For example, `src/routes/index.svelte` is the root of your site:
 
@@ -78,7 +78,7 @@ interface Fallthrough {
 }
 ```
 
-> See the [TypeScript](#typescript) section for information on `App.Locals` and `App.Platform`.
+> See the [TypeScript](/docs/typescript) section for information on `App.Locals` and `App.Platform`.
 
 A page like `src/routes/items/[id].svelte` could get its data from `src/routes/items/[id].js`:
 
@@ -102,7 +102,7 @@ export async function get({ params }) {
 }
 ```
 
-> All server-side code, including endpoints, has access to `fetch` in case you need to request data from external APIs. Don't worry about the `$lib` import, we'll get to that [later](#modules-$lib).
+> All server-side code, including endpoints, has access to `fetch` in case you need to request data from external APIs. Don't worry about the `$lib` import, we'll get to that [later](/docs/modules#$lib).
 
 The job of this function is to return a `{ status, headers, body }` object representing the response, where `status` is an [HTTP status code](https://httpstatusdogs.com):
 
@@ -111,7 +111,7 @@ The job of this function is to return a `{ status, headers, body }` object repre
 - `4xx` — client error
 - `5xx` — server error
 
-> If `{fallthrough: true}` is returned SvelteKit will [fall through](#routing-advanced-routing-fallthrough-routes) to other routes until something responds, or will respond with a generic 404.
+> If `{fallthrough: true}` is returned SvelteKit will [fall through](/docs/routing#advanced-routing-fallthrough-routes) to other routes until something responds, or will respond with a generic 404.
 
 The returned `body` corresponds to the page's props:
 
@@ -223,7 +223,7 @@ return {
 
 #### HTTP method overrides
 
-HTML `<form>` elements only support `GET` and `POST` methods natively. You can allow other methods, like `PUT` and `DELETE`, by specifying them in your [configuration](#configuration-methodoverride) and adding a `_method=VERB` parameter (you can configure the name) to the form's `action`:
+HTML `<form>` elements only support `GET` and `POST` methods natively. You can allow other methods, like `PUT` and `DELETE`, by specifying them in your [configuration](/docs/configuration#methodoverride) and adding a `_method=VERB` parameter (you can configure the name) to the form's `action`:
 
 ```js
 // svelte.config.js
@@ -252,7 +252,7 @@ Most commonly, endpoints exist to provide data to the page with which they're pa
 
 ### Private modules
 
-Files and directories with a leading `_` or `.` (other than [`.well-known`](https://en.wikipedia.org/wiki/Well-known_URI)) are private by default, meaning that they do not create routes (but can be imported by files that do). You can configure which modules are considered public or private with the [`routes`](#configuration-routes) configuration.
+Files and directories with a leading `_` or `.` (other than [`.well-known`](https://en.wikipedia.org/wiki/Well-known_URI)) are private by default, meaning that they do not create routes (but can be imported by files that do). You can configure which modules are considered public or private with the [`routes`](/docs/configuration#routes) configuration.
 
 ### Advanced routing
 
@@ -288,6 +288,6 @@ src/routes/[qux].svelte
 src/routes/foo-[bar].svelte
 ```
 
-... and you navigate to `/foo-xyz`, then SvelteKit will first try `foo-[bar].svelte` because it is the best match. If that yields no response, SvelteKit will try other less specific yet still valid matches for `/foo-xyz`. Since endpoints have higher precedence than pages, the next attempt will be `[baz].js`. Then alphabetical order takes precedence and thus `[baz].svelte` will be tried before `[qux].svelte`. The first route that responds — a page that returns something from [`load`](#loading) or has no `load` function, or an endpoint that returns something — will handle the request.
+... and you navigate to `/foo-xyz`, then SvelteKit will first try `foo-[bar].svelte` because it is the best match. If that yields no response, SvelteKit will try other less specific yet still valid matches for `/foo-xyz`. Since endpoints have higher precedence than pages, the next attempt will be `[baz].js`. Then alphabetical order takes precedence and thus `[baz].svelte` will be tried before `[qux].svelte`. The first route that responds — a page that returns something from [`load`](/docs/loading) or has no `load` function, or an endpoint that returns something — will handle the request.
 
 If no page or endpoint responds to a request, SvelteKit will respond with a generic 404.
@@ -70,7 +70,7 @@ Layout resets are otherwise identical to normal layout components.
 
 ### Error pages
 
-If a page fails to load (see [Loading](#loading)), SvelteKit will render an error page. You can customise this page by creating `__error.svelte` components alongside your layout and page components.
+If a page fails to load (see [Loading](/docs/loading)), SvelteKit will render an error page. You can customise this page by creating `__error.svelte` components alongside your layout and page components.
 
 For example, if `src/routes/settings/notifications/index.svelte` failed to load, SvelteKit would render `src/routes/settings/notifications/__error.svelte` in the same layout, if it existed. If not, it would render `src/routes/settings/__error.svelte` in the parent layout, or `src/routes/__error.svelte` in the root layout.
 
@@ -87,7 +87,7 @@ export interface ErrorLoadInput<Params extends Record<string, string> = Record<s
 }
 ```
 
-If an error component has a [`load`](#loading) function, it will be called with `error` and `status` properties:
+If an error component has a [`load`](/docs/loading) function, it will be called with `error` and `status` properties:
 
 ```html
 <script context="module">
@@ -108,6 +108,6 @@ If an error component has a [`load`](#loading) function, it will be called with
 <h1>{title}</h1>
 ```
 
-> Layout components also have access to `error` and `status` via the [page store](#modules-$app-stores)
+> Layout components also have access to `error` and `status` via the [page store](/docs/modules#$app-stores)
 >
 > Server-side stack traces will be removed from `error` in production, to avoid exposing privileged information to users.
@@ -39,7 +39,7 @@ interface Fallthrough {
 }
 ```
 
-> See the [TypeScript](#typescript) section for information on `App.Session` and `App.Stuff`.
+> See the [TypeScript](/docs/typescript) section for information on `App.Session` and `App.Stuff`.
 
 A page that loads data from an external API might look like this:
 
@@ -64,19 +64,19 @@ A page that loads data from an external API might look like this:
 
 `load` is similar to `getStaticProps` or `getServerSideProps` in Next.js, except that it runs on both the server and the client. In the example above, if a user clicks on a link to this page the data will be fetched from `cms.example.com` without going via our server.
 
-If `load` returns `{fallthrough: true}`, SvelteKit will [fall through](#routing-advanced-routing-fallthrough-routes) to other routes until something responds, or will respond with a generic 404.
+If `load` returns `{fallthrough: true}`, SvelteKit will [fall through](/docs/routing#advanced-routing-fallthrough-routes) to other routes until something responds, or will respond with a generic 404.
 
 SvelteKit's `load` receives an implementation of `fetch`, which has the following special properties:
 
 - it has access to cookies on the server
 - it can make requests against the app's own endpoints without issuing an HTTP call
 - it makes a copy of the response when you use it, and then sends it embedded in the initial page load for hydration
 
-`load` only applies to [page](#routing-pages) and [layout](#layouts) components (not components they import), and runs on both the server and in the browser with the default rendering options.
+`load` only applies to [page](/docs/routing#pages) and [layout](/docs/layouts) components (not components they import), and runs on both the server and in the browser with the default rendering options.
 
 > Code called inside `load` blocks:
 >
-> - should use the SvelteKit-provided [`fetch`](#loading-input-fetch) wrapper rather than using the native `fetch`
+> - should use the SvelteKit-provided [`fetch`](/docs/loading#input-fetch) wrapper rather than using the native `fetch`
 > - should not reference `window`, `document`, or any browser-specific objects
 > - should not directly reference any API keys or secrets, which will be exposed to the client, but instead call an endpoint that uses any required secrets
 
@@ -94,7 +94,7 @@ The `load` function receives an object containing six fields — `url`, `params`
 
 `url` is an instance of [`URL`](https://developer.mozilla.org/en-US/docs/Web/API/URL), containing properties like the `origin`, `hostname`, `pathname` and `searchParams`.
 
-> In some environments this is derived from request headers, which you [may need to configure](#configuration-headers), during server-side rendering
+> In some environments this is derived from request headers during server-side rendering. If you're using [adapter-node]/docs/adapters#supported-environments-node-js, for example, you may need to configure the adapter in order for the URL to be correct.
 
 #### params
 
@@ -123,7 +123,7 @@ If the page you're loading has an endpoint, the data returned from it is accessi
 
 #### session
 
-`session` can be used to pass data from the server related to the current request, e.g. the current user. By default it is `undefined`. See [`getSession`](#hooks-getsession) to learn how to use it.
+`session` can be used to pass data from the server related to the current request, e.g. the current user. By default it is `undefined`. See [`getSession`](/docs/hooks#getsession) to learn how to use it.
 
 #### stuff
 
@@ -161,4 +161,4 @@ If the `load` function returns a `props` object, the props will be passed to the
 
 This will be merged with any existing `stuff` and passed to the `load` functions of subsequent layout and page components.
 
-The combined `stuff` is available to components using the [page store](#modules-$app-stores) as `$page.stuff`, providing a mechanism for pages to pass data 'upward' to layouts.
+The combined `stuff` is available to components using the [page store](/docs/modules#$app-stores) as `$page.stuff`, providing a mechanism for pages to pass data 'upward' to layouts.
@@ -4,11 +4,11 @@ title: Hooks
 
 An optional `src/hooks.js` (or `src/hooks.ts`, or `src/hooks/index.js`) file exports four functions, all optional, that run on the server — **handle**, **handleError**, **getSession**, and **externalFetch**.
 
-> The location of this file can be [configured](#configuration) as `config.kit.files.hooks`
+> The location of this file can be [configured](/docs/configuration) as `config.kit.files.hooks`
 
 ### handle
 
-This function runs every time SvelteKit receives a request — whether that happens while the app is running, or during [prerendering](#page-options-prerender) — and determines the response. It receives an `event` object representing the request and a function called `resolve`, which invokes SvelteKit's router and generates a response (rendering a page, or invoking an endpoint) accordingly. This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing endpoints programmatically, for example).
+This function runs every time SvelteKit receives a request — whether that happens while the app is running, or during [prerendering](/docs/page-options#prerender) — and determines the response. It receives an `event` object representing the request and a function called `resolve`, which invokes SvelteKit's router and generates a response (rendering a page, or invoking an endpoint) accordingly. This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing endpoints programmatically, for example).
 
 > Requests for static assets — which includes pages that were already prerendered — are _not_ handled by SvelteKit.
 
@@ -38,7 +38,7 @@ export interface Handle {
 }
 ```
 
-> See the [TypeScript](#typescript) section for information on `App.Locals` and `App.Platform`.
+> See the [TypeScript](/docs/typescript) section for information on `App.Locals` and `App.Platform`.
 
 To add custom data to the request, which is passed to endpoints, populate the `event.locals` object, as shown below.
 
@@ -54,7 +54,7 @@ export async function handle({ event, resolve }) {
 }
 ```
 
-You can add call multiple `handle` functions with [the `sequence` helper function](#modules-sveltejs-kit-hooks).
+You can add call multiple `handle` functions with [the `sequence` helper function](/docs/modules#sveltejs-kit-hooks).
 
 `resolve` also supports a second, optional parameter that gives you more control over how the response will be rendered. That parameter is an object that can have the following fields:
 
@@ -71,7 +71,7 @@ export async function handle({ event, resolve }) {
 }
 ```
 
-> Disabling [server-side rendering](#appendix-ssr) effectively turns your SvelteKit app into a [**single-page app** or SPA](#appendix-csr-and-spa). In most situations this is not recommended ([see appendix](#appendix-ssr)). Consider whether it's truly appropriate to disable it, and do so selectively rather than for all requests.
+> Disabling [server-side rendering](/docs/appendix#ssr) effectively turns your SvelteKit app into a [**single-page app** or SPA](/docs/appendix#csr-and-spa). In most situations this is not recommended ([see appendix](/docs/appendix#ssr)). Consider whether it's truly appropriate to disable it, and do so selectively rather than for all requests.
 
 ### handleError
 
@@ -99,7 +99,7 @@ export async function handleError({ error, event }) {
 
 ### getSession
 
-This function takes the `event` object and returns a `session` object that is [accessible on the client](#modules-$app-stores) and therefore must be safe to expose to users. It runs whenever SvelteKit server-renders a page.
+This function takes the `event` object and returns a `session` object that is [accessible on the client](/docs/modules#$app-stores) and therefore must be safe to expose to users. It runs whenever SvelteKit server-renders a page.
 
 If unimplemented, session is `{}`.