Orbit
Frameworks et runtimes pris en charge dans Orbit
Orbit builds any project that installs with npm, yarn or pnpm and produces a folder of files or a Node.js server, and it detects the framework and package manager for you so most projects deploy…
Orbit compile tout projet qui s'installe avec npm, yarn ou pnpm et produit un dossier de fichiers ou un serveur Node.js, et il détecte le framework et le gestionnaire de paquets pour vous afin que la plupart des projets se déploient sans configuration de build du tout. Ce guide couvre ce qui est détecté, les paramètres dont chaque framework courant a besoin, quand vous devez activer le mode serveur, et comment choisir une version Node.js.
Ce qu'Orbit détecte automatiquement
Quand une compilation s'exécute, Orbit enregistre ce qu'il a trouvé et vous le montre:
- Framework, sur la page de détail du déploiement et comme badge sur les cartes de déploiement sur l'aperçu du projet.
- Gestionnaire de paquets, choisi à partir de votre fichier de verrouillage:
package-lock.jsondonne npm,yarn.lockdonne yarn,pnpm-lock.yamldonne pnpm.
Les paramètres de compilation dans Paramètres sont tous optionnels. Laissez un champ vide et son espace réservé vous indique ce qui sera utilisé à la place: Commande d'installation affiche npm ci (auto-detected), Commande de compilation affiche npm run build (auto-detected), et Répertoire de sortie affiche dist (auto-detected).
Validez exactement un fichier de verrouillage. Si package-lock.json et yarn.lock sont tous les deux dans le référentiel, le gestionnaire de paquets qu'Orbit choisit peut ne pas être celui que vous utilisez localement, et vous obtenez une installation qui se comporte différemment de votre machine sans raison visible. Supprimez celui que vous n'utilisez pas.
Paramètres par framework
Ce sont les valeurs dont chaque framework a besoin. Quand Orbit fournit un modèle de démarrage pour le framework, le modèle utilise exactement ces paramètres.
| Framework | Commande de compilation | Répertoire de sortie | Mode serveur |
|---|---|---|---|
| Next.js, export statique | npm run build | out | Désactivé |
| Next.js, SSR ou ISR | npm run build | .next | Activé |
| Astro, statique | astro build | dist | Désactivé |
| Astro, serveur ou hybride | astro build | dist | Activé |
| Vite (React, Vue, Svelte) | npm run build | dist | Désactivé |
| SvelteKit | npm run build | build | Dépend de l'adaptateur |
| Nuxt 3 | npm run build | .output | Activé |
| Remix | npm run build | build | Activé |
| Express ou une API Node simple | npm run build | dist | Activé |
| Create React App | npm run build | build | Désactivé |
| HTML simple ou un générateur statique | laissez vide, ou la commande de votre générateur | . ou le dossier qu'il écrit | Désactivé |
Vite écrit toujours dans dist sauf si vous avez défini build.outDir dans vite.config.ts. Le dossier de sortie d'Astro est dist dans chaque mode; ce qui change entre les modes est de savoir si vous avez besoin du mode serveur, pas où les fichiers arrivent.
Mode serveur
Mode serveur est un paramètre dans Paramètres, sous Runtime. Quand il est activé, Orbit maintient la machine de compilation active en exécutant npm start après chaque déploiement au lieu de servir un dossier de fichiers statiques.
Activez-le pour Next.js avec SSR, Remix, Nuxt, une API Express, et tout ce qui n'est pas un export statique. Laissez-le désactivé pour une compilation véritablement statique.
Il s'applique à partir du prochain déploiement, non au déploiement qui est actuellement en direct.
Le symptôme classique d'un mode serveur manquant est un site où la page d'accueil se charge parfaitement et chaque route dynamique retourne un 404. La compilation a réussi, les fichiers ont été publiés, et il n'y a simplement pas de serveur exécuté pour répondre aux routes. Si c'est ce que vous voyez, activez le mode serveur et redéployez avant de changer quoi que ce soit d'autre.
Version de Node.js
Définissez Version de Node.js dans Paramètres sous Paramètres de compilation. Entrez le numéro de version majeure uniquement: 18, 20 ou 22. Laissez vide pour utiliser la valeur par défaut de la plateforme.
La version s'applique à la fois à la compilation et, quand le mode serveur est activé, au runtime.
Épinglez la version explicitement plutôt que de vous fier à la valeur par défaut. Une dépendance qui nécessite une version Node plus récente que la valeur par défaut échoue l'installation avec une erreur qui ne le dit pas évidemment, et l'épinglage élimine toute une classe de défaillances de compilation « cela fonctionnait hier ».
Monorepos
Définissez Répertoire racine au sous-répertoire contenant l'application, par exemple apps/web. Orbit se change dans ce répertoire avant d'exécuter vos commandes d'installation et de compilation.
Il fait aussi quelque chose que vous voulez mais que vous ne vous attendez peut-être pas: les poussées qui ne changent que des fichiers en dehors de ce chemin sont ignorées automatiquement. Un monorepo avec quatre projets Orbit se recompile donc uniquement les applications qu'un commit a réellement touchées.
Chaque environnement peut remplacer le répertoire racine séparément, sous Staging: remplacements de compilation dans Paramètres, ce qui est utile quand la staging compile un espace de travail différent.
Paramètres de compilation personnalisés
Remplacez tout dans Paramètres, sous Paramètres de compilation:
| Champ | Exemple | Notes |
|---|---|---|
| Commande d'installation | npm ci | Ou yarn install --frozen-lockfile, pnpm install --frozen-lockfile |
| Commande de compilation | npm run build:prod | Exécuter exactement tel qu'écrit |
| Répertoire de sortie | dist/client | Le dossier publié après la compilation |
| Répertoire racine | apps/frontend | Sous-répertoire du monorepo |
| Version de Node.js | 20 | Version majeure uniquement |
Vide signifie détection automatique. Cliquez sur Enregistrer sur la carte Paramètres de compilation pour appliquer.
Staging peut remplacer n'importe lequel de ceux-ci indépendamment, dans la section Staging: remplacements de compilation. Un champ laissé vide là hérite de la valeur au niveau du projet, vous pouvez donc changer juste la commande de compilation pour staging et laisser tout le reste tel quel.
Cache de compilation
Orbit met en cache node_modules entre les compilations sur les plans Liftoff et Apex. Quand le cache est utilisé, le déploiement affiche un badge Cache hit et la phase d'installation est beaucoup plus courte. Une compilation sans elle affiche Cold build.
Pour forcer une réinstallation complète, ouvrez Paramètres, puis Effacer le cache de compilation, et confirmez. Le prochain déploiement pour chaque environnement exécute une installation complète à partir de zéro. Cela ne peut pas être annulé, et la compilation après celle-ci sera lente.
Ressources de la machine de compilation
La taille de la machine de compilation dépend de votre plan, ce qui importe pour les grandes compilations:
| Plan | vCPU | RAM | Disque | Limite de temps |
|---|---|---|---|---|
| Launch | 1 | 1 GB | 4 GB | 30 minutes |
| Liftoff | 2 | 2 GB | 8 GB | 30 minutes |
| Apex | 4 | 4 GB | 16 GB | 30 minutes |
Une compilation qui manque de mémoire ou remplit son disque échoue avec cette catégorie d'échec nommée sur la page de déploiement. Augmenter NODE_OPTIONS=--max-old-space-size aide uniquement jusqu'à la RAM réelle de la machine.
Démarrage à partir d'un modèle
Si vous voulez un déploiement fonctionnel avant d'avoir un référentiel, utilisez un modèle de démarrage. Sur Nouveau projet, basculez de Importer le référentiel Git à Démarrer à partir d'un modèle et choisissez-en un: Next.js avec shadcn/ui, un site marketing Astro, la Remix Indie Stack, un démarrage SvelteKit, une application minimale Nuxt 3, ou une API REST Express. Orbit copie le modèle, applique les bons paramètres de compilation, et le déploie.
Lectures associées
- Configuration de votre commande de compilation et du répertoire de sortie pour le détail par framework et les erreurs habituelles
- Dépannage des compilations défaillantes
- Limites du plan Orbit