Qu'est-ce que bunx et quand l'utiliser

bunx est le lanceur de paquets de Bun et un alias de bun x ; il télécharge et exécute le binaire d’un paquet depuis npm sans installation globale, exactement comme le font npx et yarn dlx.

Si vous avez déjà attendu que npx initialise une commande de scaffolding que vous exécutez une dizaine de fois par jour, ce petit délai est précisément ce que bunx cherche à éliminer. Si vous tapez déjà npx create-next-app ou npx shadcn@latest au quotidien, bunx est le substitut quasi immédiat vers lequel vous vous tournerez dès que Bun sera installé sur votre machine — à condition de comprendre une subtilité liée au runtime (--bun) et un vrai piège (les outils qui codent en dur la chaîne littérale npx) avant de faire le basculement.

Cet article vous donne le modèle mental : ce qu’est bunx, comment il résout les paquets, pourquoi il démarre plus vite que npx, ce que fait réellement le flag --bun, et une règle de décision pour savoir quand l’utiliser.

Qu’est-ce que bunx ?

bunx exécute un binaire issu d’un paquet npm sans l’installer globalement, et il est livré automatiquement avec Bun. La documentation confirme que bunx est un alias de bun x et qu’il est auto-installé lors de l’installation de bun. C’est l’équivalent Bun de npx ou de yarn dlx.

La syntaxe d’invocation est identique à celle de npx :

# npx
npx create-next-app@latest my-app

# bunx
bunx create-next-app@latest my-app

Les paquets déclarent leurs binaires dans le champ "bin" du package.json ; bunx <paquet> localise ce binaire et l’exécute. L’épinglage de version fonctionne de la même manière qu’avec npx : ajoutez @version au nom du paquet :

bunx uglify-js@3.14.0 app.js
bunx shadcn@latest add button

Lorsque le nom du binaire diffère de celui du paquet, utilisez -p/--package pour désigner explicitement le paquet, suivi du binaire :

bunx -p @angular/cli ng new my-app

Comment bunx résout-il un paquet ?

bunx vérifie d’abord la présence d’une copie installée localement, puis se rabat sur l’auto-installation depuis npm, et stocke ce qu’il installe dans le cache global de Bun pour une réutilisation ultérieure. Ce comportement est documenté : « Comme avec npx, bunx vérifie d’abord la présence d’un paquet installé localement, puis se rabat sur l’auto-installation depuis npm. » Les paquets résolus sont placés dans le cache global de Bun, de sorte que les exécutions suivantes évitent le téléchargement.

Une précision s’impose : npx moderne (npm v7+, soit npm exec) ne télécharge pas puis ne supprime pas à chaque exécution. Il maintient lui aussi un cache persistant par utilisateur et réutilise les paquets lors d’invocations répétées. La vraie différence n’est donc pas « npx jette, bunx conserve » ; les deux mettent en cache. Ce qui les distingue réellement, c’est l’emplacement du cache (le store global de Bun) et la surcharge au démarrage entre l’invocation et l’exécution.

Pourquoi bunx est-il plus rapide que npx ?

bunx démarre plus vite parce qu’il s’exécute sur le runtime de Bun, lequel est construit sur JavaScriptCore (le moteur de Safari) plutôt que de lancer Node, ce qui réduit le coût fixe de démarrage du lanceur de paquets. L’équipe Bun formule ce gain de manière concrète : lors de l’introduction de bunx, il était présenté comme permettant d’installer et d’exécuter un binaire depuis npm 100 fois plus vite que npx — un chiffre que la documentation attribue spécifiquement aux paquets déjà installés localement.

Considérez ce chiffre comme la valeur publiée par Bun pour le cas où le cache est chaud et le paquet déjà installé, et non comme un benchmark universel. L’avantage au démarrage est ce qui se généralise : pour une invocation CLI à froid (ce que vous faites des dizaines de fois par jour lors du scaffolding de projets), la moindre surcharge de lancement de processus de Bun est là où le temps est récupéré. Pour une première installation nécessitant un accès réseau, les deux outils paient le coût du téléchargement, et toute différence de vitesse se réduit au débit d’installation plus le delta de démarrage, et non à un écart de 100x.

Si vous souhaitez un chiffre fiable, mesurez vous-même en distinguant les exécutions à cache froid et à cache chaud :

# cache chaud (les deux déjà résolus) vs froid — mesurez, ne supposez pas
hyperfine 'npx cowsay hi' 'bunx cowsay hi'

Le flag —bun

Le flag --bun force un outil CLI tel que Vite, Next ou Prisma à s’exécuter sur le runtime Bun plutôt que sur Node, en ignorant le shebang #!/usr/bin/env node que l’outil embarque normalement. Par défaut, Bun respecte ce shebang et lance un processus node pour exécuter le fichier ; --bun lui indique d’utiliser le runtime Bun à la place :

bunx --bun vite dev

Le flag est sensible à la position. Il doit apparaître avant le nom de l’exécutable. Tout ce qui suit le nom est transmis directement à l’outil en tant qu’argument :

bunx --bun my-cli   # correct — exécute my-cli sur Bun
bunx my-cli --bun   # incorrect — transmet --bun à my-cli

Utilisez --bun lorsque vous souhaitez réellement que l’outil s’exécute sur Bun, pour bénéficier de son démarrage plus rapide ou de sa gestion native de TypeScript. Laissez-le de côté (comportement par défaut) lorsqu’un outil dépend de comportements spécifiques à Node ; certains outils de build et CLIs supposent des mécanismes internes de Node, et les forcer sur le runtime Bun peut faire apparaître des incompatibilités. En pratique, un cas d’échec courant est un CLI qui fonctionne avec un simple bunx toolname mais qui lève une erreur dès que --bun remplace le runtime sous-jacent. Le correctif consiste généralement à supprimer --bun et à laisser le shebang Node s’appliquer.

Quand utiliser bunx (et quand rester sur npx)

Règle de décision : utilisez bunx pour le scaffolding ponctuel et les outils CLI (bunx create-next-app my-app, bunx prisma migrate, bunx prettier foo.js) et ne conservez npx que lorsqu’un outil code en dur la chaîne littérale npx ou ne fonctionne pas sur le runtime Bun.

Le vrai piège concerne les outils qui appellent npx par son nom. Un alias shell comme alias npx=bunx fonctionne lorsque vous tapez des commandes en mode interactif, mais les alias shell n’existent que dans les shells interactifs : ils sont invisibles pour les processus non interactifs. Un outil qui appelle npx en interne (par exemple uv run qui l’invoque en sous-processus) ne verra pas l’alias du tout.

La solution consiste à placer un vrai exécutable nommé npx dans votre PATH, afin que tout processus qui lance npx résolve vers votre shim. Le contournement proposé par htdocs tient en trois lignes :

mkdir -p ~/.local/bin
printf '#!/bin/sh\nexec bunx "$@"\n' > ~/.local/bin/npx
chmod +x ~/.local/bin/npx

Assurez-vous que ~/.local/bin apparaît en tête de votre PATH. Comme il s’agit d’un vrai fichier sur le disque et non d’un alias shell, les processus non interactifs le résolvent également. Si vous souhaitez un mécanisme de repli qui ne passe par Bun que lorsqu’il est installé, une fonction wrapper conditionnelle avec une option d’échappement --real, telle que présentée par nrjdalal, est la variante plus élaborée de la même idée.

Conclusion

Considérez bunx comme npx sur un runtime plus rapide : même ordre de résolution, même syntaxe d’épinglage de version, même forme de commande, avec un démarrage à moindre surcharge et des paquets mis en cache dans le store propre à Bun. Ajoutez le flag --bun uniquement lorsque vous souhaitez que l’outil lui-même s’exécute sur Bun, placez-le avant le nom de l’exécutable, et déposez un vrai shim npx dans votre PATH pour les rares outils qui exigent la commande littérale. Installez Bun, remplacez un npx par bunx lors de votre prochain scaffolding, et mesurez la différence par vous-même.

FAQ

bunx est-il un remplacement direct de npx ?

bunx est un substitut quasi direct de npx : il partage la même syntaxe de commande, la même syntaxe d'épinglage de version avec le suffixe @version, et le même ordre de résolution local en priorité. La seule exception concerne les outils ou scripts qui appellent en interne la chaîne littérale npx, lesquels ne reconnaîtront pas bunx à moins que vous ne placiez un vrai exécutable nommé npx dans votre PATH. Dans ces cas, bunx n'est pas substitué automatiquement.

bunx fonctionne-t-il sans installer Bun séparément ?

Non, bunx nécessite Bun. bunx est un alias de la commande bun x et est auto-installé lors de l'installation de Bun lui-même ; il n'existe donc pas de paquet bunx autonome. Une fois Bun installé sur votre machine, bunx est disponible sans configuration supplémentaire. Si Bun n'est pas installé, la commande bunx n'existe pas et vous devez vous rabattre sur npx ou un autre lanceur de paquets.

Quelle est la différence entre bun x et bunx ?

Il n'y a aucune différence fonctionnelle : bunx est simplement un alias de bun x, et les deux commandes s'exécutent de manière identique. Toutes deux invoquent le lanceur de paquets de Bun pour exécuter le binaire d'un paquet sans installation globale. Utilisez la forme qui vous convient. bunx existe principalement comme forme abrégée, familière aux développeurs venant de npm qui reconnaissent immédiatement la similitude avec npx.

Pourquoi bunx --bun casse-t-il certains CLIs qui fonctionnent bien sans ce flag ?

Parce que --bun force le CLI à s'exécuter sur le runtime Bun plutôt que sur Node, en ignorant le shebang Node que l'outil embarque. Certains outils de build et CLIs dépendent de mécanismes internes spécifiques à Node ; remplacer le runtime fait alors apparaître des incompatibilités. Un outil qui fonctionne avec un simple bunx toolname peut lever une erreur dès que --bun est ajouté. Le correctif consiste à supprimer --bun et à laisser l'outil s'exécuter sur Node comme son shebang le prévoit.