Intégration SolidStart

SolidStart est le méta-framework pour SolidJS, construit sur Vinxi et Vite. solidjs-bext est l'adaptateur qui cible bext : vous conservez l'expérience de création de SolidStart, 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-solidstart dans le cadre de Jalon E7 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#

bun add -d solidjs-bext

Dépendances homologues : solid-start ^1 ou @solidjs/start ^1.

Configurer#

Dans app.config.ts ( SolidStart 1.x) :

import { defineConfig } from "@solidjs/start/config";
import bext from "solidjs-bext";

export default defineConfig({
  server: {
    preset: bext({
      runtime: "bun",
    }),
  },
});

L'adaptateur s'enregistre en tant que préréglage du serveur Vinxi. SolidStart est ensuite construit avec la sortie du serveur, produisant .output/server/index.mjs plus un répertoire .output/public d'actifs hachés.

Possibilités#

Construire#

bun run build

La build émet :

.output/
  public/            hashed JS, CSS, fonts
  server/
    index.mjs        SSR entry exporting { handler }
  bext-adapter.json  metadata for the bext runtime

bext-adapter.json est le contrat entre solidjs-bext et crates/bext-framework-solidstart. Cela ressemble à :

{
  "adapter": "solidjs-bext",
  "version": "0.1.0-preview",
  "runtime": "bun",
  "serverEntry": "server/index.mjs",
  "clientDir": "public",
  "generatedAt": "2026-04-11T12:00:00.000Z"
}

Servir#

Via bext.config.toml#

[framework]
type = "solidstart"
build_dir = ".output"

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

Alors:

bext serve

Le vhost de bext détecte le projet comme étant SolidStart (sur solid.config.* ou vite.config.* importation solid-start + solid-start / @solidjs/start dans package.json ), lit la sortie de build et distribue les requêtes au gestionnaire SolidStart via l'adaptateur d'exécution du framework.

Via bext new#

bext new my-solid-app --template @bext/starter-solid
cd my-solid-app
bun install
bun run build
bext serve

Le démarreur est livré avec app.config.ts, un shell d'application, deux itinéraires (/ et /about) et la plomberie bext.config.toml pré-câblée.

Comment ça s'articule#

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

1. solidjs-bext (ce paquet) — Adaptateur SolidStart + Vinxi préréglé. S'exécute au moment de la construction. Produit .output/ et bext-adapter.json.
2. crates/bext-framework-solidstart — Rouille Implémentation FrameworkAdapter. S'exécute au moment de la configuration du serveur. Détecte le projet, appelle bunx solid-start build (ou npx solid-start 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 SolidStart, qui à son tour les envoie au sous-processus Node/Bun en cours d'exécution. .output/server/index.mjs.

Comment cela se compare-t-il au préréglage Vinxi node-server par défaut#

Le préréglage node-server par défaut produit un serveur Node autonome que vous exécutez vous-même. solidjs-bext ignore la couche HTTP — bext le fournit — et émet simplement l'entrée SSR compilée ainsi que les actifs statiques. bext ajoute ensuite TLS, HTTP/2/3, le cache, WAF, la compression et l'écosystème complet de plugins sans que SolidStart n'ait besoin d'en connaître aucun.

Ce qui fonctionne aujourd'hui#

• Routage du système de fichiers ( src/routes/* )
• Itinéraires dynamiques avec [param].tsx
• Itinéraires fourre-tout avec [...rest].tsx
• Fonctions du serveur ( "use server" / createServerFn )
• Données d'itinéraire ( createAsync / cache )
• Îles via les wrappers clientOnly
• Actifs statiques servis à partir de .output/public

Limites actuelles#

• L'envoi du sous-processus est toujours TODO. Pour l'aperçu E7, le l'adaptateur d'exécution est uniquement un descripteur - Le handle_request de bext-framework-solidstart 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 .output/server/index.mjs, réutilisant le même sous-processus de plomberie que bext a déjà pour PHP / FastCGI.
• Aucune réponse en streaming pour l’instant. Le renderToStream de Solid peut renvoie un flux Response. L'aperçu les met en mémoire tampon. Les transmettre via le rédacteur de réponses de bext aboutit au crochet de streaming FrameworkAdapter::render.
• Aucune prise en charge du runtime Edge. Cet adaptateur cible Node / Bun. La sortie compatible avec les Workers de style Edge est hors de portée pour E7.
• Aucune version native de Rust. solidjs-bext débourse pour solid-start build — la version est un pipeline Vite + Vinxi et sa réécriture dans Rust est hors de portée pour l'E7. Un pipeline direct turbopack / chignon figure sur la feuille de route de l'écosystème.

Dépannage#

• solid-start build produced no .output/ directory — le build s'est exécuté mais n'a pas émis la mise en page attendue. Vérifiez à nouveau que votre préréglage Vinxi est bien solidjs-bext et non le node-server par défaut.
• SolidStartRuntime::handle_request is not wired yet — vous voyez la limitation du descripteur E7 uniquement. La construction fonctionne, la détection fonctionne, mais l'envoi par demande est prévu pour le suivi. En attendant, utilisez le préréglage node-server derrière bext comme proxy inverse si vous avez besoin de trafic de production maintenant.
• Legacy solid-start (pré-1.0) — la détection gère à la fois forme classique solid.config.{js,ts} et moderne Forme app.config.ts. Si vous êtes bloqué sur un ancien solid-start, l'adaptateur doit toujours s'enregistrer, mais certains hooks Vinxi peuvent ne pas exister - envisagez de passer à @solidjs/start ^1.

Documents associés#

• @bext/starter-solid — échafaudage de démarrage
• Présentation du cadre bext — comment les adaptateurs composer avec le pipeline de requêtes de bext
• Conventions de données PRISM — Style remix Exportations loader / action dans les itinéraires PRISM