```js // @noErrors import { sveltekit } from '@sveltejs/kit/vite'; ``` ## sveltekit The SvelteKit Vite plugin, which must be added to your `vite.config.js` file along with your project's configuration: ```js // @errors: 7031 /// file: vite.config.js import adapter from '@sveltejs/adapter-auto'; import { sveltekit } from '@sveltejs/kit/vite'; import { defineConfig } from 'vite'; export default defineConfig({ plugins: [ sveltekit({ adapter: adapter(), compilerOptions: { experimental: { async: true } }, experimental: { remoteFunctions: true } }) ] }); ``` As well as SvelteKit, the plugin options are used by other tooling that integrates with Svelte such as editor extensions. Any options that don't belong to SvelteKit are passed through to [`vite-plugin-svelte`](https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/config.md), so you can set options like `inspector` here too. The `experimental` namespace is shared — SvelteKit reads its own flags and forwards the rest. > [!LEGACY] > Prior to SvelteKit 3, config lived in a `svelte.config.js` file, which is no longer supported. The ability to configure SvelteKit via `vite.config.js` was added in version 2.62.
```dts function sveltekit(config?: Config): Promise; ```
## Config An extension of [`vite-plugin-svelte`'s options](https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/config.md#svelte-options).
```dts interface Config extends VitePluginSvelteOptions {/*…*/} ```
```dts adapter?: Adapter; ```
- default `undefined`
Your [adapter](/docs/kit/adapters) is run when executing `vite build`. It determines how the output is converted for different platforms.
```dts alias?: Record; ```
- deprecated - default `{}`
An object containing zero or more aliases used to replace values in `import` statements. These aliases are automatically passed to Vite and TypeScript. This option is deprecated. Use [subpath imports](/docs/kit/$lib) instead. > [!NOTE] You will need to run `npm run dev` to have SvelteKit automatically generate the required alias configuration in `jsconfig.json` or `tsconfig.json`.
```dts appDir?: string; ```
- default `"_app"`
The directory where SvelteKit keeps its stuff, including static assets (such as JS and CSS) and internally-used routes. If `paths.assets` is specified, there will be two app directories — `${paths.assets}/${appDir}` and `${paths.base}/${appDir}`.
```dts csp?: {/*…*/} ```
[Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) configuration. CSP helps to protect your users against cross-site scripting (XSS) attacks, by limiting the places resources can be loaded from. For example, a configuration like this... ```js // @errors: 7031 /// file: vite.config.js import { sveltekit } from '@sveltejs/kit/vite'; import { defineConfig } from 'vite'; export default defineConfig({ plugins: [ sveltekit({ csp: { directives: { 'script-src': ['self'] }, // must be specified with either the `report-uri` or `report-to` directives, or both reportOnly: { 'script-src': ['self'], 'report-uri': ['/'] } } }) ] }); ``` ...would prevent scripts loading from external sites. SvelteKit will augment the specified directives with nonces or hashes (depending on `mode`) for any inline styles and scripts it generates. To add a nonce for scripts and links manually included in `src/app.html`, you may use the placeholder `%sveltekit.nonce%` (for example ` ```
```dts paths?: {/*…*/} ```
```dts assets?: '' | `http://${string}` | `https://${string}`; ```
- default `""`
An absolute path that your app's files are served from. This is useful if your files are served from a storage bucket of some kind.
```dts base?: '' | `/${string}`; ```
- default `""`
A root-relative path that must start, but not end with `/` (e.g. `/base-path`), unless it is the empty string. This specifies where your app is served from and allows the app to live on a non-root path. Note that you need to prepend all your root-relative links with the base value or they will point to the root of your domain, not your `base` (this is how the browser works). You can use [`resolve(...)` from `$app/paths`](/docs/kit/$app-paths#resolve) for that: `Link`. If you find yourself writing this often, it may make sense to extract this into a reusable component.
```dts origin?: string; ```
- default `undefined` - available since v3.0
The origin of your app, used for CSRF protection and prerendering. By default, this is `undefined`, meaning SvelteKit will derive the origin from `request.url` (which is set by the adapter, and ultimately by the platform). If your app is served from an origin that isn't known at request time — for example because it's deployed to a preview deployment whose URL isn't known at build time, or because it's behind a reverse proxy that doesn't pass the `host` header — you can set this to a string like `https://my-site.com`. This is also used as the value of `url.origin` during prerendering (when unset, it defaults to `http://sveltekit-prerender`), and as the trusted origin for CSRF checks on form submissions and remote function calls.
```dts relative?: boolean; ```
- default `true` - available since v1.9.0
Whether to use relative asset paths. If `true`, paths created with `resolve()` and `asset()` imported from `$app/paths` will be replaced with relative asset paths during server-side rendering, resulting in more portable HTML. If `false`, `%sveltekit.assets%` and references to build artifacts will always be root-relative paths, unless `paths.assets` is an external URL [Single-page app](/docs/kit/single-page-apps) fallback pages will always use absolute paths, regardless of this setting. If your app uses a `` element, you should set this to `false`, otherwise asset URLs will incorrectly be resolved against the `` URL rather than the current page. In 1.0, `undefined` was a valid value, which was set by default. In that case, if `paths.assets` was not external, SvelteKit would replace `%sveltekit.assets%` with a relative path and use relative paths to reference build artifacts, but `base` and `assets` imported from `$app/paths` would be as specified in your config.
```dts prerender?: {/*…*/} ```
See [Prerendering](/docs/kit/page-options#prerender).
```dts concurrency?: number; ```
- default `1`
How many pages can be prerendered simultaneously. JS is single-threaded, but in cases where prerendering performance is network-bound (for example loading content from a remote CMS) this can speed things up by processing other tasks while waiting on the network response.
```dts crawl?: boolean; ```
- default `true`
Whether SvelteKit should find pages to prerender by following links from `entries`.
```dts entries?: Array<'*' | `/${string}`>; ```
- default `["*"]`
An array of pages to prerender, or start crawling from (if `crawl: true`). The `*` string includes all routes containing no required `[parameters]` with optional parameters included as being empty (since SvelteKit doesn't know what value any parameters should have).
```dts handleHttpError?: PrerenderHttpErrorHandlerValue; ```
- default `"fail"` - available since v1.15.7
How to respond to HTTP errors encountered while prerendering the app. - `'fail'` — fail the build - `'ignore'` - silently ignore the failure and continue - `'warn'` — continue, but print a warning - `(details) => void` — a custom error handler that takes a `details` object with `status`, `path`, `referrer`, `referenceType` and `message` properties. If you `throw` from this function, the build will fail ```js // @errors: 7031 /// file: vite.config.js import { sveltekit } from '@sveltejs/kit/vite'; import { defineConfig } from 'vite'; export default defineConfig({ plugins: [ sveltekit({ prerender: { handleHttpError: ({ path, referrer, message }) => { // ignore deliberate link to shiny 404 page if (path === '/not-found' && referrer === '/blog/how-we-built-our-404-page') { return; } // otherwise fail the build throw new Error(message); } } }) ] }); ```
```dts handleMissingId?: PrerenderMissingIdHandlerValue; ```
- default `"fail"` - available since v1.15.7
How to respond when hash links from one prerendered page to another don't correspond to an `id` on the destination page. - `'fail'` — fail the build - `'ignore'` - silently ignore the failure and continue - `'warn'` — continue, but print a warning - `(details) => void` — a custom error handler that takes a `details` object with `path`, `id`, `referrers` and `message` properties. If you `throw` from this function, the build will fail
```dts handleEntryGeneratorMismatch?: PrerenderEntryGeneratorMismatchHandlerValue; ```
- default `"fail"` - available since v1.16.0
How to respond when an entry generated by the `entries` export doesn't match the route it was generated from. - `'fail'` — fail the build - `'ignore'` - silently ignore the failure and continue - `'warn'` — continue, but print a warning - `(details) => void` — a custom error handler that takes a `details` object with `generatedFromId`, `entry`, `matchedId` and `message` properties. If you `throw` from this function, the build will fail
```dts handleUnseenRoutes?: PrerenderUnseenRoutesHandlerValue; ```
- default `"fail"` - available since v2.16.0
How to respond when a route is marked as prerenderable but has not been prerendered. - `'fail'` — fail the build - `'ignore'` - silently ignore the failure and continue - `'warn'` — continue, but print a warning - `(details) => void` — a custom error handler that takes a `details` object with a `routes` property which contains all routes that haven't been prerendered. If you `throw` from this function, the build will fail The default behavior is to fail the build. This may be undesirable when you know that some of your routes may never be reached under certain circumstances such as a CMS not returning data for a specific area, resulting in certain routes never being reached.
```dts handleInvalidUrl?: PrerenderInvalidUrlHandlerValue; ```
- default `"fail"` - available since v2.67.0
How to respond when SvelteKit encounters a URL it cannot parse while crawling prerendered HTML (for example, an AT Protocol URL such as `at://did:plc:...`). - `'fail'` — fail the build - `'ignore'` - silently ignore the failure and continue - `'warn'` — continue, but print a warning - `(details) => void` — a custom error handler that takes a `details` object with `href`, `referrer` and `message` properties. If you `throw` from this function, the build will fail
```dts router?: {/*…*/} ```
```dts type?: 'pathname' | 'hash'; ```
- default `"pathname"` - available since v2.14.0
What type of client-side router to use. - `'pathname'` is the default and means the current URL pathname determines the route - `'hash'` means the route is determined by `location.hash`. In this case, SSR and prerendering are disabled. This is only recommended if `pathname` is not an option, for example because you don't control the webserver where your app is deployed. It comes with some caveats: you can't use server-side rendering (or indeed any server logic), and you have to make sure that the links in your app all start with #/, or they won't work. Beyond that, everything works exactly like a normal SvelteKit app.
```dts resolution?: 'client' | 'server'; ```
- default `"client"` - available since v2.17.0
How to determine which route to load when navigating to a new page. By default, SvelteKit will serve a route manifest to the browser. When navigating, this manifest is used (along with the `reroute` hook, if it exists) to determine which components to load and which `load` functions to run. Because everything happens on the client, this decision can be made immediately. The drawback is that the manifest needs to be loaded and parsed before the first navigation can happen, which may have an impact if your app contains many routes. Alternatively, SvelteKit can determine the route on the server. This means that for every navigation to a path that has not yet been visited, the server will be asked to determine the route. This has several advantages: - The client does not need to load the routing manifest upfront, which can lead to faster initial page loads - The list of routes is hidden from public view - The server has an opportunity to intercept each navigation (for example through middleware in front of SvelteKit, such as a reverse proxy or your platform's edge functions), enabling (for example) A/B testing opaque to SvelteKit Route resolution requests are answered as soon as the route has been looked up, before the `handle` hook is invoked. To intercept them within SvelteKit itself, use the `reroute` hook, which runs for these requests too. The drawback is that for unvisited paths, resolution will take slightly longer (though this is mitigated by [preloading](/docs/kit/link-options#data-sveltekit-preload-data)). > [!NOTE] When using server-side route resolution and prerendering, the resolution is prerendered along with the route itself.
```dts serviceWorker?: | { /** * Whether to automatically register the service worker, if it exists. * @default true */ register: true; /** * Options for serviceWorker.register("...", options); */ options?: RegistrationOptions; } | { /** * Whether to automatically register the service worker, if it exists. * @default true */ register?: false; }; ```
```dts tracing?: {/*…*/} ```
- default `{ server: false }`
Options for enabling [OpenTelemetry](https://opentelemetry.io/) tracing for SvelteKit operations.
```dts server?: boolean; ```
- default `false`
Enables server-side [OpenTelemetry](https://opentelemetry.io/) span emission for SvelteKit operations including the [`handle` hook](/docs/kit/hooks#handle), [`load` functions](/docs/kit/load), [form actions](/docs/kit/form-actions), and [remote functions](/docs/kit/remote-functions). Tracing — and more significantly, observability instrumentation — can have a nontrivial overhead, so consider whether you really need it, or if it might be more appropriate to turn it on in development and preview environments only.
```dts typescript?: {/*…*/} ```
- deprecated Add configuration to `tsconfig.json` directly
```dts config?: (config: Record) => Record | void; ```
- default `(config) => config` - available since v1.3.0
A function that allows you to edit the generated `tsconfig.json`. You can mutate the config (recommended) or return a new one. This is useful for extending a shared `tsconfig.json` in a monorepo root, for example. Note that any paths configured here should be relative to the generated config file, which is written to `node_modules/$app/tsconfig.json`.
```dts version?: {/*…*/} ```
Client-side navigation can be buggy if you deploy a new version of your app while people are using it. If the code for the new page is already loaded, it may have stale content; if it isn't, the app's route manifest may point to a JavaScript file that no longer exists. SvelteKit helps you solve this problem through version management. The current version is included in data, remote, and form action responses via the `x-sveltekit-version` header, so SvelteKit can detect new deployments without polling — for example when a navigation triggers a server `load` function, or when a remote function is called. SvelteKit also checks for new versions when the tab regains focus or becomes visible. If SvelteKit encounters an error while loading the page and detects that a new version has been deployed (using the `name` specified here, which defaults to a timestamp of the build) it will fall back to traditional full-page navigation. Not all navigations will result in an error though, for example if the JavaScript for the next page is already loaded. If you still want to force a full-page navigation in these cases, use `beforeNavigate`: ```html /// file: +layout.svelte ``` In addition to these checks, SvelteKit polls for new versions on an interval and sets [`updated.current`](/docs/kit/$app-state#updated) to `true` when it detects one. Set `pollInterval` to `0` to disable polling (the header- and event-based checks will still run).
```dts name?: string; ```
The current app version string. If specified, this must be deterministic (e.g. a commit ref rather than `Math.random()` or `Date.now().toString()`), otherwise defaults to a timestamp of the build. For example, to use the current commit hash, you could do use `git rev-parse HEAD`: ```js // @errors: 7031 /// file: vite.config.js import * as child_process from 'node:child_process'; import { sveltekit } from '@sveltejs/kit/vite'; import { defineConfig } from 'vite'; export default defineConfig({ plugins: [ sveltekit({ version: { name: child_process.execSync('git rev-parse HEAD').toString().trim() } }) ] }); ```
```dts pollInterval?: number; ```
- default `3600000`
The interval in milliseconds to poll for version changes. If this is `0`, no polling occurs. SvelteKit also checks for new versions on server responses (via the `x-sveltekit-version` header) and when the tab regains focus or becomes visible, so polling is only needed for long-lived sessions on a single page.