import Run from "/snippets/cli/run.mdx";

Le Runtime Bun est conçu pour démarrer rapidement et s'exécuter rapidement.

Sous le capot, Bun utilise le moteur JavaScriptCore, qui est développé par Apple pour Safari. Dans la plupart des cas, les performances de démarrage et d'exécution sont plus rapides que V8, le moteur utilisé par Node.js et les navigateurs basés sur Chromium. Son transpileur et son runtime sont écrits en Zig, un langage moderne et haute performance. Sur Linux, cela se traduit par des temps de démarrage 4x plus rapides que Node.js.

Commande	Temps
bun hello.js	5,2ms
node hello.js	25,1ms

Ce benchmark est basé sur l'exécution d'un simple script Hello World sur Linux

Exécuter un fichier

Utilisez bun run pour exécuter un fichier source.

bun run index.js

Bun prend en charge TypeScript et JSX nativement. Chaque fichier est transpilé à la volée par le transpileur natif rapide de Bun avant d'être exécuté.

bun run index.js
bun run index.jsx
bun run index.ts
bun run index.tsx

Alternativement, vous pouvez omettre le mot-clé run et utiliser la commande "nue" ; elle se comporte de manière identique.

bun index.tsx
bun index.js

--watch

Pour exécuter un fichier en mode watch, utilisez l'option --watch.

bun --watch run index.tsx

::: note Lors de l'utilisation de bun run, placez les options Bun comme --watch immédiatement après bun. :::

bun --watch run dev # ✔️ faites ceci
bun run dev --watch # ❌ ne faites pas ceci

Les options qui se trouvent à la fin de la commande seront ignorées et transmises au script "dev" lui-même.

Exécuter un script package.json

::: note Comparez à npm run <script> ou yarn <script> :::

bun [options bun] run <script> [options script]

Votre package.json peut définir un certain nombre de "scripts" nommés qui correspondent à des commandes shell.

{
  // ... autres champs
  "scripts": {
    "clean": "rm -rf dist && echo 'Terminé.'",
    "dev": "bun server.ts"
  }
}

Utilisez bun run <script> pour exécuter ces scripts.

bun run clean
rm -rf dist && echo 'Terminé.'

Nettoyage...
Terminé.

Bun exécute la commande du script dans un sous-shell. Sur Linux et macOS, il vérifie les shells suivants dans l'ordre, en utilisant le premier qu'il trouve : bash, sh, zsh. Sur Windows, il utilise bun shell pour prendre en charge la syntaxe de type bash et de nombreuses commandes courantes.

NOTE

⚡️ Le temps de démarrage pour `npm run` sur Linux est d'environ 170ms ; avec Bun c'est `6ms`.

Les scripts peuvent également être exécutés avec la commande plus courte bun <script>, cependant s'il y a une commande bun intégrée avec le même nom, la commande intégrée prend le dessus. Dans ce cas, utilisez la commande plus explicite bun run <script> pour exécuter votre script de package.

bun run dev

Pour voir la liste des scripts disponibles, exécutez bun run sans aucun argument.

bun run

scripts quickstart :

 bun run clean
   rm -rf dist && echo 'Terminé.'

 bun run dev
   bun server.ts

2 scripts

Bun respecte les hooks de cycle de vie. Par exemple, bun run clean exécutera preclean et postclean, s'ils sont définis. Si le pre<script> échoue, Bun n'exécutera pas le script lui-même.

--bun

Il est courant que les scripts package.json fassent référence à des CLI installés localement comme vite ou next. Ces CLI sont souvent des fichiers JavaScript marqués avec un shebang pour indiquer qu'ils doivent être exécutés avec node.

#!/usr/bin/env node

// faire des choses

Par défaut, Bun respecte ce shebang et exécute le script avec node. Cependant, vous pouvez remplacer ce comportement avec l'option --bun. Pour les CLI basés sur Node.js, cela exécutera le CLI avec Bun au lieu de Node.js.

bun run --bun vite

Filtrage

Dans les monorepos contenant plusieurs packages, vous pouvez utiliser l'argument --filter pour exécuter des scripts dans plusieurs packages à la fois.

Utilisez bun run --filter <motif_nom> <script> pour exécuter <script> dans tous les packages dont le nom correspond à <motif_nom>. Par exemple, si vous avez des sous-répertoires contenant des packages nommés foo, bar et baz, l'exécution de

bun run --filter 'ba*' <script>

exécutera <script> dans bar et baz, mais pas dans foo.

Retrouvez plus de détails dans la page de documentation pour filter.

bun run - pour lire du code depuis stdin

bun run - vous permet de lire du JavaScript, TypeScript, TSX ou JSX depuis stdin et de l'exécuter sans écrire dans un fichier temporaire d'abord.

echo "console.log('Hello')" | bun run -

Hello

Vous pouvez également utiliser bun run - pour rediriger des fichiers dans Bun. Par exemple, pour exécuter un fichier .js comme s'il s'agissait d'un fichier .ts :

echo "console.log!('Ceci est TypeScript !' as any)" > secretly-typescript.js
bun run - < secretly-typescript.js

Ceci est TypeScript !

Par commodité, tout le code est traité comme TypeScript avec prise en charge JSX lors de l'utilisation de bun run -.

bun run --console-depth

Contrôlez la profondeur de l'inspection d'objet dans la sortie de la console avec l'option --console-depth.

bun --console-depth 5 run index.tsx

Cela définit la profondeur à laquelle les objets imbriqués sont affichés dans la sortie console.log(). La profondeur par défaut est 2. Des valeurs plus élevées affichent plus de propriétés imbriquées mais peuvent produire une sortie verbeuse pour des objets complexes.

const nested = { a: { b: { c: { d: "profond" } } } };
console.log(nested);
// Avec --console-depth 2 (par défaut) : { a: { b: [Object] } }
// Avec --console-depth 4 : { a: { b: { c: { d: 'profond' } } } }

bun run --smol

Dans les environnements à mémoire contrainte, utilisez l'option --smol pour réduire l'utilisation de la mémoire au détriment des performances.

bun --smol run index.tsx

Cela amène le garbage collector à s'exécuter plus fréquemment, ce qui peut ralentir l'exécution. Cependant, cela peut être utile dans les environnements à mémoire limitée. Bun ajuste automatiquement la taille du tas du garbage collector en fonction de la mémoire disponible (en tenant compte des cgroups et autres limites de mémoire) avec et sans l'option --smol, donc c'est surtout utile pour les cas où vous voulez que la taille du tas croisse plus lentement.

Ordre de résolution

Les chemins absolus et les chemins commençant par ./ ou .\\ sont toujours exécutés en tant que fichiers source. Sauf lors de l'utilisation de bun run, l'exécution d'un fichier avec une extension autorisée préférera le fichier à un script package.json.

Lorsqu'il y a un script package.json et un fichier avec le même nom, bun run priorise le script package.json. L'ordre de résolution complet est :

1. Scripts package.json, ex. bun run build
2. Fichiers source, ex. bun run src/main.js
3. Binaires des packages du projet, ex. bun add eslint && bun run eslint
4. (bun run uniquement) Commandes système, ex. bun run ls

---