ENbext.dev
DocumentationIntégrations de frameworks

Traduction automatique depuis l’anglais. Consulter l’original.

Sur cette page

Intégration SvelteKit

SvelteKit est le framework full-stack de Svelte avec routage du système de fichiers, actions de formulaire et SSR de première classe. @sveltejs/adapter-bext est l'adaptateur SvelteKit qui cible bext : vous conservez l'expérience de création de SvelteKit, et bext fournit la couche HTTP, le cache, le WAF, HTTP/2/3 et l'écosystème de plugins que chaque adaptateur réinvente autrement.

Version préliminaire. L'adaptateur et le framework côté Rust runtime dans le navire crates/bext-framework-sveltekit dans le cadre de Jalon E6 de bext. Voir le feuille de route de l'écosystème pour ce qui a atterri et ce qui est encore sur la liste de suivi.

Installer#

bash
bun add -d @sveltejs/adapter-bext

Dépendances homologues : @sveltejs/kit ^2.

Configurer#

Dans svelte.config.js :

js
import adapter from "@sveltejs/adapter-bext";

export default {
  kit: {
    adapter: adapter({
      out: "build",
      runtime: "bun",
    }),
  },
};

L'adaptateur implémente le contrat SvelteKit de Adapter ( adapt(builder) ) et écrit la sortie de build ainsi qu'un manifeste bext-adapter.json dans le répertoire de sortie configuré.

Possibilités#

Option Taper Défaut Description
out string "build" Répertoire dans lequel émettre les artefacts de construction.
runtime "node" | "bun" "bun" Temps d'exécution préféré pour le travailleur SSR. Informatif ; C'est bext qui décide.

Construire#

bash
bun run build

La build émet :

code
build/
  client/             hashed JS, CSS, fonts
  server/             SSR entry + manifest
  prerendered/        statically prerendered pages
  manifest.js         generated SvelteKit manifest module
  bext-adapter.json   metadata for the bext runtime

bext-adapter.json est le contrat entre @sveltejs/adapter-bext et crates/bext-framework-sveltekit. Cela ressemble à :

json
{
  "adapter": "@sveltejs/adapter-bext",
  "version": "0.1.0-preview",
  "runtime": "bun",
  "serverEntry": "server/index.js",
  "clientDir": "client",
  "prerenderedDir": "prerendered",
  "manifest": "manifest.js",
  "generatedAt": "2026-04-11T12:00:00.000Z"
}

Servir#

Via bext.config.toml#

toml
[framework]
type = "sveltekit"
build_dir = "build"

[build]
script = "build/server/index.js"
watch_dirs = ["src"]
live_reload = true

Alors:

bash
bext serve

Le vhost de bext détecte le projet comme étant SvelteKit (sur svelte.config.*

  • @sveltejs/kit dans package.json ), lit la sortie de build et distribue les requêtes au gestionnaire SvelteKit via l'adaptateur d'exécution du framework.

Via bext new#

bash
bext new my-svelte-app --template @bext/starter-sveltekit
cd my-svelte-app
bun install
bun run build
bext serve

Le démarreur est livré avec un svelte.config.js, un +layout.svelte, deux pages ( / et /about ) et la plomberie bext.config.toml pré-câblée.

Comment ça s'articule#

Trois pièces mobiles collaborent sur chaque demande SvelteKit via bext :

  1. @sveltejs/adapter-bext (ce paquet) — SvelteKit Adapter mise en œuvre. S'exécute au moment de la construction. Produit build/ et bext-adapter.json.
  2. crates/bext-framework-sveltekit — Rouille FrameworkAdapter mise en œuvre. S'exécute au moment de la configuration du serveur. Détecte le projet, appelle bunx vite build (ou npx vite build ), normalise la sortie et vend un adaptateur d'exécution.
  3. bext-server vhost — par demande. Itinéraires entrants requêtes à l'adaptateur d'exécution SvelteKit, qui à son tour les envoie au sous-processus Node/Bun en cours d'exécution. build/server/index.js.

Comment cela se compare-t-il à adapter-node#

@sveltejs/adapter-node produit un serveur Node autonome que vous exécutez vous-même. @sveltejs/adapter-bext ignore la couche HTTP — bext le fournit — et émet simplement l'entrée SSR compilée, les pages pré-rendues et les actifs client statiques. bext ajoute ensuite TLS, HTTP/2/3, le cache, WAF, la compression et l'écosystème complet de plugins sans que SvelteKit n'ait besoin d'en connaître aucun.

Si vous exécutez actuellement adapter-node derrière nginx, adapter-bext remplace les deux calques en un seul mouvement.

Ce qui fonctionne aujourd'hui#

  • Routage du système de fichiers ( src/routes/** )
  • Itinéraires dynamiques ( [param], [...rest] )
  • Mises en page et mises en page imbriquées ( +layout.svelte )
  • Fonctions de charge ( +page.server.ts, +page.ts )
  • Actions de formulaire (exportation +page.server.ts actions)
  • Itinéraires API ( +server.ts )
  • Pages pré-rendues ( export const prerender = true )
  • Actifs statiques servis à partir de build/client/
  • TypeScript + Svelte 4 et 5
Remarque

L'adaptateur E6 est un aperçu : la répartition par demande n'est pas encore câblée. Si vous avez besoin de trafic de production aujourd'hui, utilisez adapter-node derrière bext comme proxy inverse (voir multi-application ) pendant que le suivi arrive.

Limites actuelles#

  • L'envoi du sous-processus est toujours TODO. Pour l'aperçu E6, le l'adaptateur d'exécution est uniquement un descripteur - bext-framework-sveltekit handle_request renvoie une erreur non encore câblée. Le suivi consiste à apprendre au vhost du serveur bext à envoyer au sous-processus Node / Bun qui importe build/server/index.js, en réutilisant la même plomberie de sous-processus que bext a déjà pour PHP / FastCGI.
  • Aucune réponse en streaming pour l’instant. SvelteKit's handle peut revenir un flux Response. L'aperçu les met en mémoire tampon. Les transmettre via le rédacteur de réponses de bext atterrit avec le streaming Crochet FrameworkAdapter::render.
  • Aucune prise en charge du runtime Edge. Cet adaptateur cible Node / Bun. Cloudflare -La sortie Edge de type Workers est hors de portée pour E6.
  • Construction native de Rust différée. Coquilles @sveltejs/adapter-bext vers vite build — La version de SvelteKit est un ensemble de plugins Vite et sa réécriture dans Rust est hors de portée pour l'E6. Un pipeline direct turbopack / chignon figure sur la feuille de route de l'écosystème.

Dépannage#

  • vite build produced no build/ directory — la build a été exécutée mais n'a pas émis la mise en page attendue. Vérifiez à nouveau que svelte.config.js importe @sveltejs/adapter-bext et le transmet comme kit.adapter, et que le package est installé en tant que dépendance de développement.
  • SvelteKitRuntime::handle_request is not wired yet — vous êtes voir la limitation du descripteur E6 uniquement. La construction fonctionne, la détection fonctionne, mais l'envoi par demande est prévu pour le suivi. En attendant, utilisez adapter-node derrière bext comme proxy inverse si vous avez besoin de trafic de production maintenant.
  • Incompatibilité de dépendance avec SvelteKit v1 — peerDependencies est défini sur "@sveltejs/kit": "^2". Si votre fichier de verrouillage épingle la version v1, le contrat de l'adaptateur ne sera pas résolu : mettez à niveau SvelteKit ou utilisez un adaptateur plus ancien.

Documents associés#

  • SvelteKit — documentation officielle SvelteKit et contrat d'adaptateur
Modifier cette page ↗Besoin d’aide ? ↗
Rechercher dans la documentation

Saisissez un sujet, une commande ou une question.