Configuration

Mode indiquant d'utiliser des hashs ou des nonces pour restreindre les éléments <script> et <style>. 'auto' utilisera les hashs pour les pages prérendues, et des nonces pour les pages rendues dynamiquement.

Les directives qui seront ajoutées aux headers Content-Security-Policy.

Les directives qui seront ajoutées aux headers Content-Security-Policy-Report-Only.

Vérifie ou non que le header origin pour les soumissions de formulaire POST, PUT, PATCH ou DELETE correspond à l'origine du serveur.

Si vous souhaitez que des personnes puissent faire des requêtes POST, PUT, PATCH ou DELETE avec un Content-Type valant application/x-www-form-urlencoded, multipart/form-data, ou text/plain vers votre application depuis d'autres origines, vous devrez désactiver cette option. Soyez vigilants !

Le dossier dans lequel se trouve vos fichiers .env.

Un préfixe qui signale qu'une variable d'environnement est exposable en toute sécurité au code client. Voir $env/static/public et $env/dynamic/public. Notez que le préfixe envPrefix de Vite doit être défini à part si vous utilisez le gestionnaire de variables d'environnement de Vite – même si l'usage de cette fonctionnalité n'est en général pas nécessaire.

Un préfixe qui signale qu'une variable d'environnement n'est pas exposable en toute sécurité au code client. Les variables d'environnement qui ne correspondent ni au préfixe publique ni au préfixe privé seront complètement ignorées. Voir $env/static/public et $env/dynamic/public.

un endroit pour placer les fichiers statiques qui doivent avoir des URLS stables et n'être soumis à aucun traitement, comme favicon.ico ou manifest.json

la librairie interne de votre application, accessible dans votre code via $lib

un dossier contenant vos fonctions match

les fichiers qui définissent la structure de votre application (voir Routing)

l'emplacement du point d'entrée de vos service workers (voir Service workers)

l'emplacement du template pour les réponses HTML

l'emplacement du template pour les réponses d'erreur de secours

SvelteKit va précharger les modules JavaScript nécessaires pour la page initiale pour éviter des "cascades", impliquant un démarrage plus rapide de l'application. Il y a trois stratégies avec différents compromis :

• modulepreload - utilise <link rel="modulepreload">. Cette option fournit les meilleurs résultats dans les navigateurs basés sur Chromium, dans Firefox 115+, et Safari 17+. Elle est ignorée dans les navigateurs plus anciens.
• preload-js - utilise <link rel="preload">. Évite les cascades dans Chromium et Safari, mais Chromium va traiter chaque module deux fois (une fois en tant que script, une fois en tant que module). Implique que les modules sont requêtés deux fois dans Firefox. C'est une bonne option si vous souhaitez maximiser la performance sur les appareils iOS au prix d'une très légère dégradation sur Chromium.
• preload-mjs - utilise <link rel="preload"> mais avec l'extension .mjs qui empêche le double traitement par Chromium. Certains serveurs web statiques échoueront à servir les fichiers .mjs avec un header Content-Type: application/javascript, ce qui fera planter votre application. Si ceci ne s'applique pas pour vous, cette option fournira la meilleure performance pour le plus grand nombre de personnes, jusqu'à ce que modulepreload soit plus largement supporté.

Un chemin absolu depuis lequel les fichiers statiques de votre application sont servis. Ceci est utile si vos fichiers sont servis depuis un espace de stockage.

Un chemin relatif à la racine qui doit commencer, mais pas se terminer par / (par ex. /base-path), à moins que ce ne soit la chaîne de caractères vide. Ceci précise d'où votre application est servie et lui permet d'exister sur un chemin non racine. Notez que vous aurez besoin de préfixer tous vos liens relatifs à la racine avec la valeur de base, au risque de les faire pointer vers la racine de votre domaine, et non vers votre base (les navigateurs fonctionnent ainsi). Vous pouvez utiliser base importée depuis $app/paths pour faire cela: <a href="{base}/votre-page">Lien</a>. Si vous devez faire souvent ce remplacement, il peut être utile d'extraire cette logique dans un composant réutilisable.

Si oui ou non utiliser des chemins de fichiers statiques relatifs.

Si true, base et assets importées depuis $app/paths seront remplacées avec des chemins de fichiers statiques relatifs lors du rendu côté serveur, impliquant du HTML portable. Si false, %sveltekit.assets% et les références vers les artefacts de compilation seront toujours des chemins relatifs à la racine, à moins que paths.assets soit une URL externe.

Les pages de fallback des SPA utilisera toujours des chemins absolus, quelque soit la valeur de cette configuration.

Si votre application utilise un élément <base>, vous devriez définir cette option à false, sinon les URLs de fichiers statiques seront résolues par rapport à <base> plutôt que par rapport à la page courante.

Avec SvelteKit 1.0, undefined était une valeur valide, qui était celle par défaut. Dans ce cas, si paths.assets n'était pas externe, SvelteKit remplaçait %sveltekit.assets% avec un chemin relatif et utilisait des chemins relatifs pour référencer les artéfacts générés ; mais base et assets importés depuis $app/paths étaient résolues comme définis dans votre configuration.

Nombre de pages pouvant être prérendues simultanément. JS ne s'exécute que sur un seul thread, mais dans les cas où la performance de prérendu est liée au réseau (par exemple en chargeant du contenu depuis un CMS distant) ceci peut accélérer le processus en effectuant d'autres tâches pendant que les requêtes se terminent.

Si oui ou non SvelteKit devrait trouver des pages à prérendre en suivant des liens depuis les entrées entries.

Un tableau de pages à prérendre, ou depuis lequel commencer à chercher des liens (si crawl: true). La chaîne de caractères * permet d'inclure toutes les routes non dynamiques (c'est-à-dire les pages sans [parametres] ou vide, car SvelteKit ne sait pas d'avance les valeurs que vos paramètres peuvent avoir).

Comportement de SvelteKit lors d'erreurs HTTP rencontrées pendant le prérendu de l'application.

• 'fail' — fait échouer la compilation
• 'ignore' - ignore l'erreur en silence et continue
• 'warn' — continue, mais affiche un avertissement
• (details) => void — un gestionnaire d'erreur personnalisé qui prend en entrée un objet details possédant les propriétés status, path, referrer, referenceType et message. Si vous utilisez throw depuis cette fonction, la compilation échouera

ts
/** @type {import('@sveltejs/kit').Config} */
const config = {
	kit: {
		prerender: {
			handleHttpError: ({ path, referrer, message }) => {
				// ignore délibérément le lien vers une page 404
				if (path === '/not-found' && referrer === '/blog/how-we-built-our-404-page') {
					return;
				}

				// sinon fait échouer la compilation
				throw new Error(message);
			}
		}
	}
};

Comportement de SvelteKit lorsque les liens d'une page prérendue vers une autre ne correspondent pas à l'id de la page cible.

• 'fail' — fait échouer la compilation
• 'ignore' - ignore l'erreur en silence et continue
• 'warn' — continue, mais affiche un avertissement
• (details) => void — un gestionnaire d'erreur personnalisé qui prend en entrée un objet details possédant les propriétés path, id, referrers et message. Si vous utilisez throw depuis cette fonction, la compilation échouera

Comportement de SvelteKit lorsqu'une entrée générée par l'export entries ne correspond pas à la route depuis laquelle elle a été générée.

• 'fail' — fait échouer la compilation
• 'ignore' - ignore l'erreur en silence et continue
• 'warn' — continue, mais affiche un avertissement
• (details) => void — un gestionnaire d'erreur personnalisé qui prend en entrée un objet details possédant les propriétés generatedFromId, entry, matchedId et message. Si vous utilisez throw depuis cette fonction, la compilation échouera

La valeur de url.origin pendant le prérendu ; utile si l'origine est incluse dans le contenu généré.

Si oui ou non utiliser automatiquement le service worker, s'il existe.

Détermine quels fichiers de votre dossier static seront disponibles dans $service-worker.files.

Une fonction qui permet d'éditer le fichier tsconfig.json généré. Vous pouvez muter la configuration (recommandé) ou en renvoyer une nouvelle. Ceci est utile pour étender un fichier tsconfig.json partagé à la racine d'un monorepo, par exemple.

La version actuelle de votre application. Si précisée, cette valeur doit être déterministe (c'est-à-dire une référence de commit plutôt qu'un Math.random() ou Date.now().toString()). Si non précisée, cette valeur vaut le timestamp de la dernière compilation.

Par exemple, pour utiliser le hash du dernier commit, vous pouvez utiliser git rev-parse HEAD :

ts
import * as child_process from 'node:child_process';

export default {
	kit: {
		version: {
			name: child_process.execSync('git rev-parse HEAD').toString().trim()
		}
	}
};

Un intervalle en millisecondes pour vérifier l'existence de nouvelles version. Si cette valeur vaut 0, aucune vérification n'est faite.