Skip to main content

Foire À Questions

Autres ressources

Visitez la FÀQ de Svelte ainsi que la FÀQ de vite-plugin-svelte pour les questions relatives à ces librairies.

Que puis-je construire avec SvelteKit ?

Voir la documentation concernant les types de projet pour plus d’informations.

Comment inclure des informations du fichier package.json dans mon application ?

Si vous souhaitez inclure le numéro de version de votre application ou d’autres informations provenant du fichier package.json au sein de votre application, vous pouvez charger le JSON de cette manière :

svelte.config
import pkg from './package.json' with { type: 'json' };

Comment corriger l’erreur qui se produit lorsque j’essaie d’ajouter un paquet ?

La plupart des erreurs qui se produisent lorsque l’on ajoute une librairie sont liées à un mauvais packaging. Vous pouvez vérifier si le packaging d’une librairie est compatible avec Node.js en entrant son nom sur le site de publint.

Voici quelques informations à avoir en tête lorsque vous vérifiez si une librairie est packagée correctement :

  • exports prend la précédence sur les autres points d’entrée comme main et module. Ajouter un champ exports peut ne pas être retro-compatible puisque cela empêche les imports profonds.
  • Les fichiers ESM devraient avoir un nom se terminant en .mjs à moins que "type": "module" ne soit précisé, auquel cas les fichiers CommonJS devraient avoir un nom se terminant en .cjs.
  • main devrait être défini si exports ne l’est pas. Il doit correspondre soit à un fichier CommonJS ou ESM et adhérer au point précédent. Si un champ module est défini, il doit faire référence à un fichier ESM.
  • Les composants Svelte devraient être distribués en tant que fichiers .svelte non compilés avec tout autre fichier JS du paquet écrit exclusivement en ESM. Les scripts personnalisés et les langages de style, comme TypeScript et SCSS, devraient être préprocessés en tant que JS et CSS vanille respectivement. Nous recommandons d’utiliser svelte-package pour packager des librairies Svelte, qui se chargera de tout cela pour vous.

Les librairies fonctionnent mieux dans le navigateur avec Vite lorsqu’elles fournissent une version ESM, particulièrement si elles sont une dépendance d’une librairie de composants Svelte. Vous pourriez suggérer aux auteurs et autrices de librairies qu’elles fournissent une version ESM. Toutefois, les dépendances CommonJS (CJS) devraient fonctionner quand même puisque, par défaut, vite-plugin-svelte va demander à Vite de les pré-compiler en utilisant esbuild pour les convertir en ESM.

Si vous rencontrez toujours des problèmes, nous recommandons de chercher du côté des issues Vite et/ou des issues de la librairie en question. Parfois des issues peuvent être contournées en jouant avec les valeurs des options de configuration optimizeDeps ou ssr, bien que nous ne recommandions cela qu’en tant que solution temporaire en attendant que la librairie concernée soit corrigée.

Comment utiliser l’API View Transition ?

Bien que SvelteKit n’ait pas d’intégration spécifique avec les view transitions, vous pouvez exécuter document.startViewTransition dans onNavigate pour déclencher une transition de vue pour chaque navigation côté client.

import { onNavigate } from '$app/navigation';

onNavigate((navigation) => {
	if (!document.startViewTransition) return;

	return new Promise((resolve) => {
		document.startViewTransition(async () => {
			resolve();
			await navigation.complete;
		});
	});
});

Pour plus de détails, voir l’article “Unlocking view transitions” sur le blog de Svelte.

Comment mettre en place une base de données ?

Mettez le code pour requêter votre base de données dans une route de serveur — ne requêtez pas la base de données dans des fichiers .svelte. Vous pouvez créer un fichier db.js ou similaire permettant de mettre en place la connexion immédiatement afin de rendre accessible le client de base de données accessible dans votre application en tant que singleton. Vous pouvez exécuter tout code de mise en place ne devant être exécuté qu’une seule fois dans le fichier hooks.server.js et importer vos utilitaires de base de données dans tout endpoint qui les nécessiterait.

Vous pouvez utiliser le CLI de Svelte pour mettre en place des intégrations de base de données automatiquement.

Comment utiliser une librairie client qui a besoin d’accéder à document ou window ?

Si vous avez besoin d’accéder aux variables document ou window, ou si vous avez besoin que du code s’exécute uniquement côté client, vous pouvez l’entourer d’une condition vérifiant la valeur de browser :

import { browser } from '$app/environment';

if (browser) {
	// votre code uniquement client se place ici
}

Vous pouvez aussi exécuter du code dans onMount si vous souhaitez qu’il soit exécuté après que le premier composant ait été rendu dans le DOM :

import { onMount } from 'svelte';

onMount(async () => {
	const { method } = await import('some-browser-only-library');
	method('bonjour tout le monde');
});

Si la librairie que vous souhaitez utiliser ne possède pas d’effets de bord, vous pouvez également l’importer statiquement et elle sera supprimée (grâce au tree-shaking) du build serveur dans lequel onMount sera automatiquement remplacée par une opération blanche (“no-op”) :

import { onMount } from 'svelte';
import { method } from 'some-browser-only-library';

onMount(() => {
	method('bonjour tout le monde');
});

Enfin, vous pouvez également envisager d’utiliser un block {#await} :

index
<script>
	import { browser } from '$app/environment';

	const promise = browser
		? import('./BrowserComponent.svelte')
		: import('./ServerComponent.svelte');
</script>

{#await promise}
	<p>Chargement...</p>
{:then module}
	<module.default />
{:catch error}
	<p>Quelque chose s'est mal passé : {error.message}</p>
{/await}
<script lang="ts">
	import { browser } from '$app/environment';

	const promise = browser
		? import('./BrowserComponent.svelte')
		: import('./ServerComponent.svelte');
</script>

{#await promise}
	<p>Chargement...</p>
{:then module}
	<module.default />
{:catch error}
	<p>Quelque chose s'est mal passé : {error.message}</p>
{/await}

Comment utiliser un serveur d’API différent ?

Vous pouvez utiliser event.fetch pour requêter des données depuis un serveur d’API externe, mais soyez conscient•e que vous aurez à gérer les CORS, qui vont engendrer des complications telles qu’imposer des requêtes préliminaires, ce qui augmente la latence. Les requêtes vers un sous-domaine séparé peuvent également augmenter la latence à cause d’une recherche DNS additionnelle, de la mise en place du TLS, etc. Si vous souhaitez utiliser cette méthode, vous pourriez trouver la méthode handleFetch utile.

Une autre approche est de définir un proxy pour contourner les galères de CORS. En production, vous pourriez ré-écrire un chemin comme /api vers le serveur d’API ; en local, utilisez l’option server.proxy de Vite.

La bonne manière de mettre en place des ré-écritures de chemin en production dépend généralement de votre plateforme de déploiement. Si les ré-écritures ne sont pas possibles, vous pouvez toujours ajouter une route d’API :

src/routes/api/[...path]/+server
/** @type {import('./$types').RequestHandler} */
export function GET({ params, url }) {
	return fetch(`https://example.com/${params.path + url.search}`);
}
import type { RequestHandler } from './$types';

export const GET: RequestHandler = ({ params, url }) => {
	return fetch(`https://example.com/${params.path + url.search}`);
};

(Notez que vous pourriez également vouloir ajouter un proxy pour les requêtes POST / PATCH etc., et relayer les en-têtes request.headers, en fonction de vos besoins.)

Comment utiliser des middleware ?

L’adaptateur adapter-node construit un middleware que vous pouvez utiliser avec votre propre serveur pour le mode production. En mode dev, vous pouvez ajouter des middleware à Vite en utilisant un plugin Vite. Par exemple :

vite.config
import { sveltekit } from '@sveltejs/kit/vite';

/** @type {import('vite').Plugin} */
const myPlugin = {
	name: 'log-request-middleware',
	configureServer(server) {
		server.middlewares.use((req, res, next) => {
			console.log(`Requête reçue sur ${req.url}`);
			next();
		});
	}
};

/** @type {import('vite').UserConfig} */
const config = {
	plugins: [myPlugin, sveltekit()]
};

export default config;
import { sveltekit } from '@sveltejs/kit/vite';
import type { Plugin, UserConfig } from 'vite';

const myPlugin: Plugin = {
	name: 'log-request-middleware',
	configureServer(server) {
		server.middlewares.use((req, res, next) => {
			console.log(`Requête reçue sur ${req.url}`);
			next();
		});
	}
};

const config: UserConfig = {
	plugins: [myPlugin, sveltekit()]
};

export default config;

Voir la documentation de Vite sur configureServer pour plus de détails sur comment gérer l’ordre des middleware.

Comment utiliser Yarn ?

Est-ce que Yarn 2 est compatible ?

En quelque sorte. La fonctionalité Plug’n’Play, appelée ‘pnp’, ne fonctionnera pas (cette fonctionnalité ne suit pas l’algorithme de résolution de modules de Node, et ne fonctionne pas encore avec les modules JavaScript natifs, ce que SvelteKit — ainsi qu’un nombre croissant de paquets — utilise). Vous pouvez utiliser nodeLinker: 'node-modules' dans votre fichier .yarnrc.yml pour désactiver le pnp, mais il sera probablement plus facile de simplement utiliser npm ou pnpm, qui est tout aussi rapide et efficace, les problèmes de compatibilité en moins.

Comment se servir de Yarn 3 ?

Actuellement la dernière version (3) de Yarn supporte de manière expérimentale les ESM.

L’exemple ci-dessous semble fonctionner même si les résultats peuvent être différents. Créez d’abord une nouvelle application :

yarn create svelte myapp
cd myapp

Puis activez Yarn Berry :

yarn set version berry
yarn install

L’une des fonctionnalités les plus intéressantes de Yarn Berry est la possibilité d’avoir un seul cache global pour les paquets, plutôt que d’avoir plusieurs copies sur votre disque pour chacun de vos projets. Toutefois, définir enableGlobalCache à true provoque l’échec de la compilation, il est donc recommandé d’ajouter la chose suivante au fichier .yarnrc.yml :

nodeLinker: node-modules

Ceci va impliquer que les paquets seront téléchargés dans un dossier node_modules local tout en évitant le problème décrit ci-dessus, et est votre meilleure option pour utiliser la version 3 de Yarn à l’heure actuelle.

Modifier cette page sur Github llms.txt

précédent suivant