Merge branch 'main' into main

Author: DreaminDani

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,4 @@
-### A note on documentation PRs
-
-If this is a documentation PR (i.e. changing content within `apps/svelte.dev/content/docs`), then this is the wrong repository to make those changes. The content in this folder is synced from other repositories. Therefore, these changes should be made in their respective repositories (at https://github.com/sveltejs/svelte or https://github.com/sveltejs/kit, or example).
+<!-- If this is a documentation PR (i.e. changing content within `apps/svelte.dev/content/docs`), then this is the wrong repository to make those changes. The content in this folder is synced from other repositories. Therefore, these changes should be made in their respective repositories (at https://github.com/sveltejs/svelte or https://github.com/sveltejs/kit, or example). -->
 
 ### Before submitting the PR, please make sure you do the following
 

apps/svelte.dev/content/blog/2017-09-06-the-zen-of-just-writing-css.md

@@ -17,7 +17,7 @@ This article isn't in any way intended as criticism of the hard work the CSS-in-
 
 Everything in CSS is global. Because of that, styles intended for one bit of markup often end up affecting another. Because of _that_, developers often resort to wild namespacing conventions (not 'rules', since they're very difficult to enforce) that mostly just increase your risk of RSI.
 
-It gets worse when you're working on a team. No-one dares touch styles authored by someone else, because it's often unclear what they're doing, what markup they apply to, and what disasters will unfold if you remove them.
+It gets worse when you're working on a team. No one dares touch styles authored by someone else, because it's often unclear what they're doing, what markup they apply to, and what disasters will unfold if you remove them.
 
 The consequence of all this is the **append-only stylesheet**. There's no way of knowing which code can safely be removed, so it's common to undo some existing style with another, more specific style — even on relatively small projects.
 

apps/svelte.dev/content/blog/2018-12-27-virtual-dom-is-pure-overhead.md

@@ -42,7 +42,7 @@ Misunderstood claims about virtual DOM performance date back to the launch of Re
 	<figcaption>Screenshot from <a href="https://www.youtube.com/watch?v=x7cQ3mrcKaY">Rethinking Best Practices</a> at JSConfEU 2013</figcaption>
 </figure>
 
-But hang on a minute! The virtual DOM operations are _in addition to_ the eventual operations on the real DOM. The only way it could be faster is if we were comparing it to a less efficient framework (there were plenty to go around back in 2013!), or arguing against a straw man — that the alternative is to do something no-one actually does:
+But hang on a minute! The virtual DOM operations are _in addition to_ the eventual operations on the real DOM. The only way it could be faster is if we were comparing it to a less efficient framework (there were plenty to go around back in 2013!), or arguing against a straw man — that the alternative is to do something no one actually does:
 
 ```js
 // @noErrors

apps/svelte.dev/content/blog/2023-03-09-zero-config-type-safety.md

@@ -98,7 +98,7 @@ export type PageData = Kit.ReturnType<
 >;
 ```
 
-We don't actually write `$types.d.ts` into your `src` directory — that would be messy, and no-one likes messy code. Instead, we use a TypeScript feature called [`rootDirs`](https://www.typescriptlang.org/tsconfig#rootDirs), which lets us map ‘virtual’ directories to real ones. By setting `rootDirs` to the project root (the default) and additionally to `.svelte-kit/types` (the output folder of all the generated types) and then mirroring the route structure inside it we get the desired behavior:
+We don't actually write `$types.d.ts` into your `src` directory — that would be messy, and no one likes messy code. Instead, we use a TypeScript feature called [`rootDirs`](https://www.typescriptlang.org/tsconfig#rootDirs), which lets us map ‘virtual’ directories to real ones. By setting `rootDirs` to the project root (the default) and additionally to `.svelte-kit/types` (the output folder of all the generated types) and then mirroring the route structure inside it we get the desired behavior:
 
 ```tree
 // on disk:

apps/svelte.dev/content/docs/kit/10-getting-started/20-creating-a-project.md

@@ -5,7 +5,7 @@ title: Creating a project
 
 The easiest way to start building a SvelteKit app is to run `npx sv create`:
 
-```bash
+```sh
 npx sv create my-app
 cd my-app
 npm install

apps/svelte.dev/content/docs/kit/20-core-concepts/40-page-options.md

@@ -89,7 +89,7 @@ Since these routes cannot be dynamically server-rendered, this will cause errors
 
 SvelteKit will discover pages to prerender automatically, by starting at _entry points_ and crawling them. By default, all your non-dynamic routes are considered entry points — for example, if you have these routes...
 
-```bash
+```sh
 /             # non-dynamic
 /blog         # non-dynamic
 /blog/[slug]  # dynamic, because of `[slug]`

apps/svelte.dev/content/docs/kit/25-build-and-deploy/40-adapter-node.md

@@ -27,7 +27,7 @@ First, build your app with `npm run build`. This will create the production serv
 
 You will need the output directory, the project's `package.json`, and the production dependencies in `node_modules` to run the application. Production dependencies can be generated by copying the `package.json` and `package-lock.json` and then running `npm ci --omit dev` (you can skip this step if your app doesn't have any dependencies). You can then start your app with this command:
 
-```bash
+```sh
 node build
 ```
 
@@ -45,41 +45,41 @@ In `dev` and `preview`, SvelteKit will read environment variables from your `.en
 
 In production, `.env` files are _not_ automatically loaded. To do so, install `dotenv` in your project...
 
-```bash
+```sh
 npm install dotenv
 ```
 
 ...and invoke it before running the built app:
 
-```bash
+```sh
 node +++-r dotenv/config+++ build
 ```
 
 If you use Node.js v20.6+, you can use the [`--env-file`](https://nodejs.org/en/learn/command-line/how-to-read-environment-variables-from-nodejs) flag instead:
 
-```bash
+```sh
 node +++--env-file=.env+++ build
 ```
 
 ### `PORT`, `HOST` and `SOCKET_PATH`
 
 By default, the server will accept connections on `0.0.0.0` using port 3000. These can be customised with the `PORT` and `HOST` environment variables:
 
-```bash
+```sh
 HOST=127.0.0.1 PORT=4000 node build
 ```
 
 Alternatively, the server can be configured to accept connections on a specified socket path. When this is done using the `SOCKET_PATH` environment variable, the `HOST` and `PORT` environment variables will be disregarded.
 
-```bash
+```sh
 SOCKET_PATH=/tmp/socket node build
 ```
 
 ### `ORIGIN`, `PROTOCOL_HEADER`, `HOST_HEADER`, and `PORT_HEADER`
 
 HTTP doesn't give SvelteKit a reliable way to know the URL that is currently being requested. The simplest way to tell SvelteKit where the app is being served is to set the `ORIGIN` environment variable:
 
-```bash
+```sh
 ORIGIN=https://my.site node build
 
 # or e.g. for local previewing and testing
@@ -88,7 +88,7 @@ ORIGIN=http://localhost:3000 node build
 
 With this, a request for the `/stuff` pathname will correctly resolve to `https://my.site/stuff`. Alternatively, you can specify headers that tell SvelteKit about the request protocol and host, from which it can construct the origin URL:
 
-```bash
+```sh
 PROTOCOL_HEADER=x-forwarded-proto HOST_HEADER=x-forwarded-host node build
 ```
 
@@ -104,7 +104,7 @@ If `adapter-node` can't correctly determine the URL of your deployment, you may
 
 The [`RequestEvent`](@sveltejs-kit#RequestEvent) object passed to hooks and endpoints includes an `event.getClientAddress()` function that returns the client's IP address. By default this is the connecting `remoteAddress`. If your server is behind one or more proxies (such as a load balancer), this value will contain the innermost proxy's IP address rather than the client's, so we need to specify an `ADDRESS_HEADER` to read the address from:
 
-```bash
+```sh
 ADDRESS_HEADER=True-Client-IP node build
 ```
 
@@ -175,7 +175,7 @@ If you need to change the name of the environment variables used to configure th
 envPrefix: 'MY_CUSTOM_';
 ```
 
-```bash
+```sh
 MY_CUSTOM_HOST=127.0.0.1 \
 MY_CUSTOM_PORT=4000 \
 MY_CUSTOM_ORIGIN=https://my.site \

apps/svelte.dev/content/docs/kit/25-build-and-deploy/70-adapter-cloudflare-workers.md

@@ -65,14 +65,14 @@ https://dash.cloudflare.com/<your-account-id>/home
 
 You will need to install [Wrangler](https://developers.cloudflare.com/workers/wrangler/install-and-update/) and log in, if you haven't already:
 
-```bash
+```sh
 npm i -D wrangler
 wrangler login
 ```
 
 Then, you can build your app and deploy it:
 
-```bash
+```sh
 wrangler deploy
 ```
 

apps/svelte.dev/content/docs/kit/25-build-and-deploy/90-adapter-vercel.md

@@ -132,7 +132,7 @@ Set this string as an environment variable on Vercel by logging in and going to
 
 To get this key known about for local development, you can use the [Vercel CLI](https://vercel.com/docs/cli/env) by running the `vercel env pull` command locally like so:
 
-```bash
+```sh
 vercel env pull .env.development.local
 ```
 

apps/svelte.dev/content/docs/kit/30-advanced/10-advanced-routing.md

@@ -7,7 +7,7 @@ title: Advanced routing
 
 If the number of route segments is unknown, you can use rest syntax — for example you might implement GitHub's file viewer like so...
 
-```bash
+```sh
 /[org]/[repo]/tree/[branch]/[...file]
 ```
 
@@ -102,7 +102,7 @@ Each module in the `params` directory corresponds to a matcher, with the excepti
 
 It's possible for multiple routes to match a given path. For example each of these routes would match `/foo-abc`:
 
-```bash
+```sh
 src/routes/[...catchall]/+page.svelte
 src/routes/[[a=x]]/+page.svelte
 src/routes/[b]/+page.svelte
@@ -119,7 +119,7 @@ SvelteKit needs to know which route is being requested. To do so, it sorts them
 
 ...resulting in this ordering, meaning that `/foo-abc` will invoke `src/routes/foo-abc/+page.svelte`, and `/foo-def` will invoke `src/routes/foo-[c]/+page.svelte` rather than less specific routes:
 
-```bash
+```sh
 src/routes/foo-abc/+page.svelte
 src/routes/foo-[c]/+page.svelte
 src/routes/[[a=x]]/+page.svelte