Merge branch 'main' into main

Author: teemingc

.changeset/dry-hornets-change.md

@@ -0,0 +1,5 @@
+---
+'@sveltejs/adapter-node': patch
+---
+
+fix: validate `ORIGIN` env var at startup

.changeset/fix-layout-children-forwarding-warning.md

@@ -0,0 +1,5 @@
+---
+'@sveltejs/kit': patch
+---
+
+fix: suppress false-positive inner content warning when children prop is forwarded to a child component

.changeset/fuzzy-maps-sort.md

@@ -0,0 +1,5 @@
+---
+'@sveltejs/adapter-cloudflare': patch
+---
+
+fix: error if `_routes.json` is in the `/static` public directory

.changeset/quiet-onions-accept.md

@@ -0,0 +1,5 @@
+---
+'@sveltejs/adapter-cloudflare': patch
+---
+
+fix: correctly handle pathnames found in the `_redirects` file

.changeset/scroll-state-navigation.md

@@ -0,0 +1,12 @@
+---
+'@sveltejs/kit': minor
+---
+
+feat: add `scroll` property to `NavigationTarget` in navigation callbacks
+
+Navigation callbacks (`beforeNavigate`, `onNavigate`, and `afterNavigate`) now include scroll position information via the `scroll` property on `from` and `to` targets:
+
+- `from.scroll`: The scroll position at the moment navigation was triggered
+- `to.scroll`: In `beforeNavigate` and `onNavigate`, this is populated for `popstate` navigations (back/forward) with the scroll position that will be restored, and `null` for other navigation types. In `afterNavigate`, this is always the final scroll position after navigation completed.
+
+This enables use cases like animating transitions based on the target scroll position when using browser back/forward navigation.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,6 @@
-<!-- Your PR description here -->
+closes #<!-- Add the related issue number here. Repeat this line for each additional issue it closes -->
+
+<!-- Explain the goal of the PR, why it is needed, and what has been changed to achieve that goal -->
 
 ---
 

documentation/docs/25-build-and-deploy/10-building-your-app.md

@@ -14,10 +14,10 @@ SvelteKit will load your `+page/layout(.server).js` files (and all files they im
 
 ```js
 +++import { building } from '$app/environment';+++
-import { setupMyDatabase } from '$lib/server/database';
+import { initialiseDatabase } from '$lib/server/database';
 
 +++if (!building) {+++
-	setupMyDatabase();
+	initialiseDatabase();
 +++}+++
 
 export function load() {

documentation/docs/25-build-and-deploy/60-adapter-cloudflare.md

@@ -73,6 +73,7 @@ Only for Cloudflare Pages. Allows you to customise the [`_routes.json`](https://
 - `exclude` defines routes that will _not_ invoke a function — this is a faster and cheaper way to serve your app's static assets. This array can include the following special values:
 	- `<build>` contains your app's build artifacts (the files generated by Vite)
 	- `<files>` contains the contents of your `static` directory
+	- `<redirects>` contains a list of pathnames from your [`_redirects` file](https://developers.cloudflare.com/pages/configuration/redirects/) at the root
 	- `<prerendered>` contains a list of prerendered pages
 	- `<all>` (the default) contains all of the above
 

documentation/docs/30-advanced/20-hooks.md

@@ -159,7 +159,7 @@ export const getTodo = query(v.string(), (id) => {
 });
 ```
 
-...but it is called with something that doesn't match the schema — such as a number (e.g `await getTodos(1)`) — then validation will fail, the server will respond with a [400 status code](https://http.dog/400), and the function will throw with the message 'Bad Request'.
+...but it is called with something that doesn't match the schema — such as a number (e.g. `await getTodos(1)`) — then validation will fail, the server will respond with a [400 status code](https://http.dog/400), and the function will throw with the message 'Bad Request'.
 
 To customise this message and add additional properties to the error object, implement `handleValidationError`:
 

documentation/docs/30-advanced/70-packaging.md

@@ -157,7 +157,7 @@ This will treat only the specified files as having side effects.
 
 ## TypeScript
 
-You should ship type definitions for your library even if you don't use TypeScript yourself so that people who do get proper intellisense when using your library. `@sveltejs/package` makes the process of generating types mostly opaque to you. By default, when packaging your library, type definitions are auto-generated for JavaScript, TypeScript and Svelte files. All you need to ensure is that the `types` condition in the [exports](#Anatomy-of-a-package.json-exports) map points to the correct files. When initialising a library project through `npx sv create`, this is automatically setup for the root export.
+You should ship type definitions for your library even if you don't use TypeScript yourself so that people who do get proper intellisense when using your library. `@sveltejs/package` makes the process of generating types mostly opaque to you. By default, when packaging your library, type definitions are auto-generated for JavaScript, TypeScript and Svelte files. All you need to ensure is that the `types` condition in the [exports](#Anatomy-of-a-package.json-exports) map points to the correct files. When initialising a library project through `npx sv create`, this is automatically set up for the root export.
 
 If you have something else than a root export however — for example providing a `your-library/foo` import — you need to take additional care for providing type definitions. Unfortunately, TypeScript by default will _not_ resolve the `types` condition for an export like `{ "./foo": { "types": "./dist/foo.d.ts", ... }}`. Instead, it will search for a `foo.d.ts` relative to the root of your library (i.e. `your-library/foo.d.ts` instead of `your-library/dist/foo.d.ts`). To fix this, you have two options:
 
@@ -187,7 +187,7 @@ You can read more about that feature [here](https://www.typescriptlang.org/docs/
 
 ## Best practices
 
-You should avoid using SvelteKit-specific modules like `$app/environment` in your packages unless you intend for them to only be consumable by other SvelteKit projects. E.g. rather than using `import { browser } from '$app/environment'` you could use `import { BROWSER } from 'esm-env'` ([see esm-env docs](https://github.com/benmccann/esm-env)). You may also wish to pass in things like the current URL or a navigation action as a prop rather than relying directly on `$app/state`, `$app/navigation`, etc. Writing your app in this more generic fashion will also make it easier to setup tools for testing, UI demos and so on.
+You should avoid using SvelteKit-specific modules like `$app/environment` in your packages unless you intend for them to only be consumable by other SvelteKit projects. E.g. rather than using `import { browser } from '$app/environment'` you could use `import { BROWSER } from 'esm-env'` ([see esm-env docs](https://github.com/benmccann/esm-env)). You may also wish to pass in things like the current URL or a navigation action as a prop rather than relying directly on `$app/state`, `$app/navigation`, etc. Writing your app in this more generic fashion will also make it easier to set up tools for testing, UI demos and so on.
 
 Ensure that you add [aliases](configuration#alias) via `svelte.config.js` (not `vite.config.js` or `tsconfig.json`), so that they are processed by `svelte-package`.