Types

The name of the adapter, using for logging. Will typically correspond to the package name.

This function is called after SvelteKit has built your app.

The type of navigation:

• enter: The app has hydrated
• form: The user submitted a <form>
• link: Navigation was triggered by a link click
• goto: Navigation was triggered by a goto(...) call or a redirect
• popstate: Navigation was triggered by back/forward navigation

Since afterNavigate is called after a navigation completes, it will never be called with a navigation that unloads the page.

Call this to prevent the navigation from starting.

Print messages to the console. log.info and log.minor are silent unless Vite's logLevel is info.

Remove dir and all its contents.

Create dir and any required parent directories.

The fully resolved svelte.config.js.

Information about prerendered pages and assets, if any.

An array of all routes (including prerendered)

Create separate functions that map to one or more routes of your app.

Generate a fallback page for a static webserver to use when no route is matched. Useful for single-page apps.

Generate a server-side manifest to initialise the SvelteKit server with.

Resolve a path to the name directory inside outDir, e.g. /path/to/.svelte-kit/my-adapter.

Get the fully resolved path to the directory containing client-side assets, including the contents of your static directory.

Get the fully resolved path to the directory containing server-side code.

Get the application path including any configured base path, e.g. /my-base-path/_app.

Write client assets to dest.

Write prerendered files to dest.

Write server-side code to dest.

Copy a file or directory.

Compress files in directory with gzip and brotli, where appropriate. Generates .gz and .br files alongside the originals.

Gets a cookie that was previously set with cookies.set, or from the request headers.

Gets all cookies that were previously set with cookies.set, or from the request headers.

Sets a cookie. This will add a set-cookie header to the response, but also make the cookie available via cookies.get or cookies.getAll during the current request.

The httpOnly and secure options are true by default (except on http://localhost, where secure is false), and must be explicitly disabled if you want cookies to be readable by client-side JavaScript and/or transmitted over HTTP. The sameSite option defaults to lax.

By default, the path of a cookie is the 'directory' of the current pathname. In most cases you should explicitly set path: '/' to make the cookie available throughout your app.

Deletes a cookie by setting its value to an empty string and setting the expiry date in the past.

By default, the path of a cookie is the 'directory' of the current pathname. In most cases you should explicitly set path: '/' to make the cookie available throughout your app.

Serialize a cookie name-value pair into a Set-Cookie header string, but don't apply it to the response.

The httpOnly and secure options are true by default (except on http://localhost, where secure is false), and must be explicitly disabled if you want cookies to be readable by client-side JavaScript and/or transmitted over HTTP. The sameSite option defaults to lax.

By default, the path of a cookie is the current pathname. In most cases you should explicitly set path: '/' to make the cookie available throughout your app.

The HTTP status code, in the range 400-599.

The content of the error.

fetch is equivalent to the native fetch web API, with a few additional features:

• It can be used to make credentialed requests on the server, as it inherits the cookie and authorization headers for the page request.
• It can make relative requests on the server (ordinarily, fetch requires a URL with an origin when used in a server context).
• Internal requests (e.g. for +server.js.ts routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
• During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the text and json methods of the Response object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
• During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.

You can learn more about making credentialed requests with cookies here

Contains the data returned by the route's server load function (in +layout.server.js.ts or +page.server.js.ts), if any.

If you need to set headers for the response, you can do so using the this method. This is useful if you want the page to be cached, for example:

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
    const url = `https://cms.example.com/articles.json`;
    const response = await fetch(url);

    setHeaders({
        age: response.headers.get('age'),
        'cache-control': response.headers.get('cache-control')
    });

    return response.json();
}

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 the cookies API in a server-only load function instead.

setHeaders has no effect when a load function runs in the browser.

await parent() returns data from parent +layout.js.ts load functions. Implicitly, a missing +layout.js.ts is treated as a ({ data }) => data function, meaning that it will return and forward data from parent +layout.server.js.ts files.

Be careful not to introduce accidental waterfalls when using await parent(). If for example you only want to merge parent data into the returned output, call it after fetching your other data.

This function declares that the load function has a dependency on one or more URLs or custom identifiers, which can subsequently be used with invalidate() to cause load to rerun.

Most of the time you won't need this, as fetch calls depends on your behalf — it's only necessary if you're using a custom API client that bypasses fetch.

URLs can be absolute or relative to the page being loaded, and must be encoded.

Custom identifiers have to be prefixed with one or more lowercase letters followed by a colon to conform to the URI specification.

The following example shows how to use depends to register a dependency on a custom identifier, which is invalidated after a button click, making the load function rerun.

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
    depends('increase:count');

    return { count: count++ };
}

<script>
    import { invalidate } from '$app/navigation';

    export let data;

    const increase = async () => {
        await invalidate('increase:count');
    }
</script>

<p>{data.count}<p>
<button on:click={increase}>Increase Count</button>

Where navigation was triggered from

Where navigation is going to/has gone to

The type of navigation:

• form: The user submitted a <form>
• leave: The user is leaving the app by closing the tab or using the back/forward buttons to go to a different document
• link: Navigation was triggered by a link click
• goto: Navigation was triggered by a goto(...) call or a redirect
• popstate: Navigation was triggered by back/forward navigation

Whether or not the navigation will result in the page being unloaded (i.e. not a client-side navigation)

In case of a history back/forward navigation, the number of steps to go back/forward

The parameters of the current page - e.g. for a route like /blog/[slug], a { slug: string } object

Info about the current route

ts
id: RouteId;

The URL of the current page

Parameters of the target page - e.g. for a route like /blog/[slug], a { slug: string } object. Is null if the target is not part of the SvelteKit app (could not be resolved to a route).

Info about the target route

The URL that is navigated to

The URL of the current page

The parameters of the current page - e.g. for a route like /blog/[slug], a { slug: string } object

Info about the current route

ts
id: RouteId;

Http status code of the current page

The error object of the current page, if any. Filled from the handleError hooks.

The merged result of all data from all load functions on the current page. You can type a common denominator through App.PageData.

Filled only after a form submission. See form actions for more info.

The HTTP status code, in the range 300-308.

The location to redirect to.

Get or set cookies related to the current request

fetch is equivalent to the native fetch web API, with a few additional features:

• It can be used to make credentialed requests on the server, as it inherits the cookie and authorization headers for the page request.
• It can make relative requests on the server (ordinarily, fetch requires a URL with an origin when used in a server context).
• Internal requests (e.g. for +server.js.ts routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
• During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the text and json methods of the Response object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
• During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.

You can learn more about making credentialed requests with cookies here

The client's IP address, set by the adapter.

Contains custom data that was added to the request within the handle hook.

The parameters of the current route - e.g. for a route like /blog/[slug], a { slug: string } object

Additional data made available through the adapter.

The original request object

Info about the current route

ts
id: RouteId;

If you need to set headers for the response, you can do so using the this method. This is useful if you want the page to be cached, for example:

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
    const url = `https://cms.example.com/articles.json`;
    const response = await fetch(url);

    setHeaders({
        age: response.headers.get('age'),
        'cache-control': response.headers.get('cache-control')
    });

    return response.json();
}

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 the cookies API instead.

The requested URL.

true if the request comes from the client asking for +page/layout.server.js.ts data. The url property will be stripped of the internal information related to the data request in this case. Use this property instead if the distinction is important to you.

true for +server.js.ts calls coming from SvelteKit without the overhead of actually making an HTTP request. This happens when you make same-origin fetch requests on the server.

Applies custom transforms to HTML. If done is true, it's the final chunk. Chunks are not guaranteed to be well-formed HTML (they could include an element's opening tag but not its closing tag, for example) but they will always be split at sensible boundaries such as %sveltekit.head% or layout/page components.

Determines which headers should be included in serialized responses when a load function loads a resource with fetch. By default, none will be included.

Determines what should be added to the <head> tag to preload it. By default, js and css files will be preloaded.

private fields

await parent() returns data from parent +layout.server.js.ts load functions.

Be careful not to introduce accidental waterfalls when using await parent(). If for example you only want to merge parent data into the returned output, call it after fetching your other data.

This function declares that the load function has a dependency on one or more URLs or custom identifiers, which can subsequently be used with invalidate() to cause load to rerun.

Most of the time you won't need this, as fetch calls depends on your behalf — it's only necessary if you're using a custom API client that bypasses fetch.

URLs can be absolute or relative to the page being loaded, and must be encoded.

Custom identifiers have to be prefixed with one or more lowercase letters followed by a colon to conform to the URI specification.

The following example shows how to use depends to register a dependency on a custom identifier, which is invalidated after a button click, making the load function rerun.

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
    depends('increase:count');

    return { count: count++ };
}

<script>
    import { invalidate } from '$app/navigation';

    export let data;

    const increase = async () => {
        await invalidate('increase:count');
    }
</script>

<p>{data.count}<p>
<button on:click={increase}>Increase Count</button>

A string that uniquely identifies an HTTP service (e.g. serverless function) and is used for deduplication. For example, /foo/a-[b] and /foo/[c] are different routes, but would both be represented in a Netlify _redirects file as /foo/:param, so they share an ID

A function that compares the candidate route with the current route to determine if it should be grouped with the current route.

Use cases:

• Fallback pages: /foo/[c] is a fallback for /foo/a-[b], and /[...catchall] is a fallback for all routes
• Grouping routes that share a common config: /foo should be deployed to the edge, /bar and /baz should be deployed to a serverless function

A function that is invoked once the entry has been created. This is where you should write the function to the filesystem and generate redirect manifests.

A map of path to { file } objects, where a path like /foo corresponds to foo.html and a path like /bar/ corresponds to bar/index.html.

A map of path to { type } objects.

A map of redirects encountered during prerendering.

An array of prerendered paths (without trailing slashes, regardless of the trailingSlash config)