CLI

La CLI bext génère, exécute, construit et inspecte les applications PRISM. Cette page liste les commandes utilisées pour développer une application ; pour la configuration qu'elles lisent, voir la Référence de configuration.

Commandes

Commande Rôle
bext new <nom> --template <modèle> Générer une nouvelle application à partir d'un modèle de démarrage.
bext dev [dossier] Démarrer le serveur de développement local avec rechargement à chaud, sur 127.0.0.1.
bext build Lancer le build défini dans la section [build] de la configuration.
bext run [dossier] Détecter le framework, construire si un build est configuré, puis servir l'application.
bext routes [dossier] Afficher les routes détectées.

dev, run et routes prennent le dossier de l'application en argument (. par défaut). dev et run lisent le bext.config.toml de ce dossier ; build et routes lisent celui du dossier courant.

bext new

Générer une nouvelle application à partir d'un modèle de démarrage :

bext new my-app --template @bext/starter-prism
cd my-app
bext dev

Le modèle est téléchargé depuis le registre bext, puis ses fichiers sont écrits dans un nouveau dossier my-app. La commande échoue si ce dossier existe déjà. Les étapes post-installation déclarées par le modèle (par exemple git init) sont ensuite exécutées ; un modèle ne peut lancer que des étapes d'une liste autorisée, jamais une commande shell arbitraire.

Option Effet
--template <modèle> Identifiant du modèle dans le registre.
--from-path <dossier> Charger le modèle depuis un dossier local au lieu du registre (pour tester un modèle non publié).
--no-post-install Ne pas exécuter les étapes post-installation (les messages d'information s'affichent quand même).

--template ou --from-path est obligatoire.

Modèles de démarrage

Modèle Pour
@bext/starter-prism Une application PRISM minimale : composants serveur JSX, cache ISR, une route d'API. Le point de départ pour PRISM.
@bext/starter-blog Un blog en Markdown, avec flux RSS et plan du site.
@bext/starter-docs Un site de documentation en Markdown, avec barre latérale tirée de l'arborescence des fichiers.
@bext/starter-saas Une application SaaS : page d'accueil, tarifs, tableau de bord réservé aux utilisateurs connectés.
@bext/starter-api Une application API uniquement, sans interface.

Seul @bext/starter-prism génère une application PRISM ; les quatre autres utilisent le mode template de bext (un serveur TypeScript dans server/).

bext dev

Démarrer le serveur de développement sur votre machine, avec rechargement à chaud. Les modifications dans le dossier de l'application, le dossier statique et les watch_dirs de [build] sont poussées au navigateur : une modification CSS seule est appliquée sans recharger la page, les autres rechargent la page.

Le serveur écoute sur le port défini par listen dans la section [server] de votre configuration, ou 3061 à défaut (3000 si le dossier n'a pas de bext.config.toml). Si l'hôte configuré est 0.0.0.0 (ou absent), il est remplacé par 127.0.0.1 : le serveur reste sur la boucle locale tant que vous ne passez pas --listen. Si le port est déjà pris, bext dev essaie les ports suivants et affiche celui qu'il a retenu. Le fichier .env du dossier de l'application est chargé au démarrage.

bext dev
bext dev --port 3001
bext dev --listen 0.0.0.0:8080 --open
bext dev --no-hmr
Option Effet
-p, --port N Écouter sur le port N, en gardant l'hôte configuré (127.0.0.1 par défaut).
-l, --listen hôte:port Écouter sur un hôte et un port explicites (par exemple 0.0.0.0:8080 pour exposer le serveur sur votre réseau). Avec --port en plus, le port est celui de --port.
--open Ouvrir l'application dans le navigateur au démarrage.
--no-hmr Désactiver le rechargement à chaud (ni WebSocket ni script injecté dans les pages).

bext build

Lancer le build configuré dans la section [build] du bext.config.toml du dossier courant : le script défini par script (exécuté avec Bun), ou Turbopack si engine = "turbopack". Le CSS Tailwind est généré d'abord, sauf avec --no-css.

bext build
bext build --no-css
Option Effet
--no-css Ne pas régénérer le CSS et garder le styles.css existant.

Sans script ni engine = "turbopack", la commande s'arrête avec une erreur. Une application PRISM qui compile ses pages à la première requête (on_demand = true dans [compile], comme le modèle @bext/starter-prism) n'a pas besoin de cette étape.

bext run

Détecter le framework de l'application et la servir. Si [build] définit un build, il est lancé au démarrage ; en cas d'échec, le serveur démarre quand même et l'erreur est journalisée.

bext run .
bext run . --port 8080
Option Effet
-p, --port N Écouter sur le port N, en gardant l'hôte configuré.
-l, --listen hôte:port Écouter sur un hôte et un port explicites. Avec --port en plus, le port est celui de --port.
-w, --workers N Nombre de workers de rendu.
--open Ouvrir l'application dans le navigateur au démarrage.

Contrairement à bext dev, bext run garde l'hôte configuré : avec la valeur par défaut, il écoute sur 0.0.0.0:3061, donc sur toutes les interfaces. Sans bext.config.toml, la configuration est déduite du framework détecté, sur le port 3000.

Si l'argument est un fichier .ts, .tsx, .js, .mjs, .cjs ou .jsx, bext run exécute ce script une fois au lieu de démarrer un serveur. Les arguments placés après -- sont transmis au script :

bext run scripts/seed.ts -- --dry-run

bext routes

Afficher le framework retenu pour le dossier donné (ou, sans argument, pour le app_dir de la configuration), puis la table des routes de pages (motif, route dynamique ou non, métadonnées, generateStaticParams) et celle des routes d'API avec leurs méthodes et leur fichier :

bext routes
bext routes ./my-app

Voir aussi