Skip to main content

​
CLI Kazzle

Utilisez le CLI Kazzle pour exécuter les commandes d’application en développement et en aperçu :
Tout ce qui suit -- est la vraie commande. Kazzle injecte d’abord l’environnement d’exécution. kazzle run est réservé au développement et à l’aperçu. Il doit figurer dans le script dev, jamais dans start. En production, l’exécution déployée injecte PORT, HOST et les secrets directement, et la commande de production est la commande brute (par ex. bun run index.ts). Le CLI kazzle n’est pas installé dans les images déployées, donc une commande de production qui appelle kazzle run échoue avec kazzle: command not found.

​
Ce que kazzle run injecte

  • les secrets de l’entrée env du composant dans kazzle.config.ts
  • PORT et HOST
  • les URL des composants frères comme KAZZLE_APP_COMPONENT_SERVER_URL
  • l’identité d’exécution Kazzle telle que l’ID d’application et le nom du composant

​
Exemple

dev s’exécute via kazzle run pour que Kazzle puisse injecter le port d’aperçu et l’env d’exécution. start est la commande brute — la production injecte elle-même PORT/HOST/secrets. Ne mettez pas les noms de collections de secrets dans package.json. Mettez-les dans kazzle.config.ts.

​
Lier un checkout à une application

kazzle run doit savoir à quelle application ce répertoire appartient. Ordre de résolution :
  1. --app=<appId> sur la ligne de commande
  2. la variable d’env KAZZLE_APP_ID (définie automatiquement quand Kazzle démarre un composant supervisé)
  3. .kazzle/link.json remonté depuis le répertoire courant
Si aucun de ces éléments ne se résout, kazzle run quitte avec :
app { create: {} } écrit <checkout>/.kazzle/link.json automatiquement — comme le .vercel/project.json de Vercel. Le fichier est par clone et gitignored. Après un git clone frais d’une application existante, exécutez :
L’IA peut réparer un lien manquant à partir d’un thread avec app { link: { appId } }.