Bun 1.4 : fonctions intégrées pouvant remplacer sharp, Puppeteer, node-pty et d’autres

Un projet JavaScript typique accumule une dépendance pour chaque fonctionnalité dont il a besoin : sharp pour les images, un analyseur Markdown, Playwright ou Puppeteer pour l’automatisation des navigateurs, une bibliothèque cron, node-pty pour les pseudo-terminals, concurrently ou npm-run-all pour des scripts en parallèle, ainsi qu’une multitude de configurations CI afin d’accélérer les tests. Bun 1.4 adopte une approche différente : de nombreuses de ces tâches peuvent être exécutées directement au sein du runtime. Ce guide présente les nouveaux outils intégrés, accompagnés des exemples nécessaires pour les tester, et propose une méthode à faible risque pour les évaluer.

D’après l’annonce de sortie, Bun 1.4 a été déployé le 20 août 2026, ajoutant plus de 1 500 tests de compatibilité avec Node.js, corrigeant plus de 2 900 problèmes et réduisant l’utilisation inutile de la CPU et de la mémoire. Les API de cette nouvelle version peuvent encore évoluer, il convient donc de considérer les détails ci-dessous comme un aperçu provisoire et de les vérifier auprès de l’annonce officielle de Bun 1.4 ainsi que des documents actuels. Le thème de cette mise à jour concerne moins la vitesse brute que la réduction de l’ensemble des outils nécessaires.

Installation ou mise à niveau

Bun peut être installé à l’aide d’un script shell, de npm, de Homebrew, de PowerShell sous Windows, ou en tant qu’image Docker. Chaque ligne étiquetée ci-dessous représente une alternative ; choisissez celle qui correspond à votre environnement :

--curl
curl -fsSL https://bun.sh/install | bash

--npm
npm install -g bun

--brew
brew install oven-sh/bun/bun

--powershell
powershell -c "irm bun.sh/install.ps1 | iex"

--docker
docker pull oven/bun

Si Bun est déjà installé sur votre machine, une seule commande vous amènera à la dernière version :

bun upgrade

Traitement d’images avec Bun.Image

Bun.Image intègre dans l’environnement de exécution la décodage, le redimensionnement, la rotation et l’encodage des formats courants, vous évitant ainsi de dépendre d’images natives. La chaîne suivante lit un JPEG, l’insère dans une boîte de 1024 par 1024 tout en conservant le rapport d’aspect, le fait pivoter, l’encode en WebP avec une qualité de 85 et enregistre le résultat :

await Bun.file("photo.jpg")
  .image()
  .resize(1024, 1024, { fit: "inside" })
  .rotate(90)
  .webp({ quality: 85 })
  .write("thumb.webp");

Comme chaque étape renvoie le même constructeur, la chaîne de traitement s’exécute du haut vers le bas comme une recette. Les utilisations typiques incluent la création de miniatures pour les téléchargements, le redimensionnement des avatars, la conversion JPEG en WebP, les API d’images et l’optimisation des ressources avant qu’elles ne soient stockées.

Bun indique que son implémentation surpasse sharp dans plusieurs de ses propres tests de performance, notamment pour la redimensionnement et l’encodage d’un PNG en 1080p. L’avantage majeur réside dans l’élimination d’un module natif qui complique souvent les builds Docker et les caches CI. Si vous dépendez de fonctionnalités avancées de sharp, assurez-vous que les opérations que vous utilisez existent avant de faire le changement.

Automatisation d’un navigateur sans interface avec Bun.WebView

Bun.WebView est une API de navigateur sans interface intégrée qui permet de naviguer, cliquer, faire défiler, évaluer du JavaScript et capturer des captures d’écran. Notez la déclaration await using : elle lie la durée de vie du navigateur au bloc contenant l’appel, ce qui permet à celui-ci d’être libéré automatiquement lorsque le bloc se termine, même en cas d’erreur.

await using view = new Bun.WebView({
  width: 800,
  height: 600,
});

await view.navigate("https://bun.sh");
await view.click("a[href='/docs']");
const title = await view.evaluate("document.title");
await Bun.write(
  "page.png",
  await view.screenshot()
);

Le script ouvre une page, suit un lien, lit le titre du document et enregistre une capture d’écran. Cela permet de gérer de nombreuses tâches simples sans avoir recours à un framework d’automatisation complet : services de capture d’écran, tests de fonctionnement de base, outils de scraping, vérifications de disponibilité, outils de contrôle des liens et flux de QA simples. Lorsqu’on a besoin d’un contrôle plus poussé, Bun.WebView offre un accès au Chrome DevTools Protocol. Pour de grandes suites d’essais bout en bout nécessitant une compatibilité entre navigateurs, un outil dédié reste probablement la meilleure solution.

Rendu de Markdown avec Bun.markdown

Bun.markdown convertit le Markdown en plusieurs formats. La version la plus simple renvoie une chaîne HTML :

const html = Bun.markdown.html(
  "# Hello **world**"
);

Il peut également générer directement des éléments React, ce qui est pratique lorsque un composant affiche une page README ou des documents :

export default function Page() {
  return Bun.markdown.react(readme);
}

Le rendu peut être davantage personnalisé, par exemple pour formater la sortie destinée à un terminal. Les extensions Markdown spécifiques à GitHub telles que les tableaux, les listes de tâches, l’effacement et les liens automatiques sont prises en charge. Cela convient aux sites de documentation, aux portails de développeurs, aux blogs, aux afficheurs de README, à l’aide en ligne de commande, aux bases de connaissances ainsi qu’aux interfaces affichant du Markdown généré par un modèle.

Un point important prime sur tous les autres : la sortie HTML n’est pas nettoyée. Tout Markdown provenant d’utilisateurs, de tiers ou d’un LLM doit passer par un outil de nettoyage avant d’arriver dans le navigateur, sinon vous risquez une injection de script.

Tâches planifiées avec Bun.cron

Bun.cron() fonctionne en deux modes. Dans le premier, il enregistre une tâche auprès du planificateur du système d’exploitation : crontab sous Linux, launchd sous macOS et le Planificateur de tâches sous Windows. La fonction prend en paramètre un chemin vers un script, une expression cron et un nom de tâche ; celle-ci exécute un processus travailleur chaque lundi à 02:30 :

await Bun.cron(
  "./worker.ts",
  "30 2 * * MON",
  "weekly-report"
);

Puisque c’est le système d’exploitation qui gère le planning, la tâche s’exécute même en l’absence de processus Bun actif. Dans le second mode, le planning est géré par le processus en cours d’exécution, ce qui entraîne son exécution toutes les cinq minutes. La déclaration using arrête la tâche à la fin de son champ d’application :

using job = Bun.cron(
  "*/5 * * * *",
  async () => {
    await cleanupTempFiles();
  }
);

Les exécutions ne se chevauchent jamais, et les fuseaux horaires explicites sont pris en charge. De bons candidats sont les tâches de nettoyage, les rapports, la maintenance des bases de données, la synchronisation des données, les envois groupés d’e-mails et les consultations périodiques. Gardez à l’esprit que les tâches en cours disparaissent lorsque le processus est redémarré, et si vous exécutez plusieurs répliques, chacune s’exécutera à moins d’ajouter une mécanisme de coordination.

Exécution simultanée des scripts

bun run --parallel remplace concurrently et npm-run-all. Transmettez plusieurs noms de scripts pour les exécuter en même temps :

bun run --parallel build test

Les modèles globaux sélectionnent un ensemble de scripts :

bun run --parallel "build:*"

En combinaison avec --filter, le même paramètre exécute un script dans tous les espaces de travail :

bun run --parallel --filter '*' build

Normalement, une seule erreur arrête tout ; --no-exit-on-error permet aux tâches restantes de se terminer, ce qui est utile pour collecter toutes les erreurs de test en même temps :

bun run --parallel --no-exit-on-error --filter '*' test

Chaque ligne de sortie est précédée du script qui l’a générée, ce qui permet aux journaux entremêlés de rester lisible. Dans un monorepo, cela remplace une chaîne séquentielle comme celle ci-dessous par des tâches réparties sur les cœurs de votre processeur :

package A → build
package B → build
package C → build

Les exécutions parallèles ne comprennent pas les dépendances entre paquets ; donc, si un paquet doit être compilé avant un autre, vous avez encore besoin d’un ordre précis ou d’un exécuteur de tâches capable de modéliser ce graphe.

Exécutions de tests plus rapides

bun test dispose désormais d’un flag --parallel :

bun test --parallel

Vous pouvez définir explicitement le nombre de processus travailleurs :

bun test --parallel=4

Les fichiers sont transmis aux processus travailleurs de manière dynamique, plutôt que d’être divisés à l’avance en lots fixes ; ainsi, un fichier lent ne laisse pas les autres processus inactifs. Trois flags liés ciblent les environnements CI. Le sharding répartit le ensemble de tests sur plusieurs machines, ici en prenant la première des trois parties :

bun test --shard=1/3

Exécuter uniquement les tests affectés par vos modifications raccourcit les boucles de retour local :

bun test --changed

Enregistrer les durées permet aux exécutions ultérieures d’équilibrer le travail en utilisant des données de chronométrage réelles :

bun test --timings=timings.json

L’exécution parallèle met en évidence les tests qui partagent un état, tels qu’une base de données commune, des ports fixes ou des fichiers temporaires. Prévoyez de corriger certains problèmes d’isolation dès la première activation.

Résolution des dépendances vulnérables

La maintenance de la sécurité dispose d’une commande intégrée :

bun audit fix

Celle-ci met à jour les paquets vulnérables vers des versions corrigées et les installe. Lorsqu’une correction nécessite une augmentation de version majeure, Bun en signale l’existence sans l’appliquer ; ajoutez --latest pour l’activer. Examinez ces mises à jour majeures comme toute modification perturbatrice. Dans le CI, cela intègre la sécurité des dépendances à l’étape d’installation normale.

Suppression des dépendances dupliquées

Les grands projets comportent souvent plusieurs versions presque identiques d’un même paquet :

esbuild@0.15.10
esbuild@0.15.11

Lorsqu’une seule version répond à toutes les exigences, cette commande supprime les doublons :

bun dedupe

La variante de vérification échoue avec une erreur si des doublons subsistent, ce qui en fait un point de contrôle naturel dans les pipelines CI :

bun dedupe --check

Moins de doublons signifient des arbres de dépendances plus petits, des installations plus rapides, une utilisation moindre du disque, une maintenance simplifiée et éventuellement des déploiements plus petits.

Exécution de programmes interactifs avec Bun.Terminal

Bun.Terminal est un pseudo-terminal intégré qui permet à JavaScript de contrôler des programmes interactifs sans avoir recours à node-pty :

bash
vim
htop

Bun.Terminal pertinent pour les outils de développement, les CLI, les tableaux de bord de terminal, les outils de développement à distance, l’automatisation interactive et les agents de codage IA, qui travaillent de plus en plus directement dans une shell.

Compatibilité avec Node.js et Next.js

Le changement ayant le plus grand impact pourrait être la compatibilité plutôt que de nouvelles API. Cette version ajoute 1 517 tests Node.js et indique des améliorations dans les modules http, fs, stream, cluster, timers, zlib et vm. Elle met également en avant un meilleur soutien dans plusieurs catégories : les frameworks (Next.js 16, Nuxt, Fastify), les outils de test (Vitest, Playwright, Testcontainers), l’observabilité (OpenTelemetry et dd-trace de Datadog) ainsi que les clients de données ou d’infrastructure (TypeORM, RabbitMQ et AWS S3).

L’option --bun force l’interface en ligne de commande d’un outil à s’exécuter sous Bun plutôt que sous le binaire Node.js indiqué dans son shebang. Selon la documentation de sortie, cela fonctionne avec Next.js 16.3, Turbopack et le React Compiler :

bun --bun next build

L’adoption dépend finalement du fait que votre application existante survive au passage à ce nouveau système, donc une compilation réussie de votre propre projet vaut plus que n’importe quel résultat de benchmark publié.

Les affirmations sur les performances dans leur contexte

Les benchmarks de Bun pour la version 1.4 montrent une consommation CPU en veille jusqu’à cinq fois inférieure, une utilisation de la mémoire significativement plus faible dans les charges de travail HTTP, ainsi qu’un démarrage plus rapide sous Linux et Windows. Il s’agit de chiffres fournis par le fournisseur, il convient donc de les interpréter comme indicatifs. Une consommation CPU, une utilisation de la mémoire et un temps de démarrage plus faibles peuvent se traduire par des services moins chers et plus réactifs, mais seuls vos propres charges de travail peuvent le confirmer. Pour une vue plus complète des compromis liés au temps d’exécution, consultez notre comparaison de Node.js, Deno et Bun.

Une manière à faible risque d’évaluer Bun 1.4

Mettre à jour un système de production en bloc est rarement judicieux. Des expériences petites et réversibles fonctionnent mieux.

Démarrer une nouvelle API

Créez un squelette de projet et développez un petit service à l’aide de Bun.serve :

bun init

Remplacer un flux de travail d’image

Transférez une seule chaîne de traitement sharp vers Bun.Image et comparez la qualité du résultat ainsi que le temps de traitement.

Déplacer une tâche planifiée

Sélectionnez une simple tâche cron et réimplémentez-la à l’aide de Bun.cron().

Paralléliser vos tests

Exécutez l’ensemble des tests existants en parallèle et notez quels tests échouent en raison d’un état partagé :

bun test --parallel

Nettoyer les dépendances

Testez les commandes de sécurité et de suppression des doublons sur une branche et examinez le diff généré :

bun audit fix
bun dedupe

Construire votre application Next.js avec Bun

Exécutez la compilation de production avec l’environnement d’exécution Bun et comparez-la à votre pipeline actuel :

bun --bun next build

Dans tous les cas, mesurez les résultats plutôt que de vous fier à des benchmarks publiés.

La tendance à la consolidation

Bun 1.4 ne se concentre pas tant sur une liste de nouvelles API que sur un environnement d’exécution capable d’absorber les fonctions qui appartenaient auparavant à des packages distincts. La structure générale se compose d’une couche d’environnement d’exécution avec les API de Node.js, d’une couche d’outils couvrant les tests, les scripts, la sécurité, le CI et les terminaux, ainsi que d’une couche de bibliothèques pour les images, Markdown, les navigateurs et cron :

Bun 1.4
               │
     ┌─────────┼──────────┐
     │         │          │
 Runtime    Tooling    Libraries
     │         │          │
 Node.js     Testing    Image
 APIs        Scripts    Markdown
             Security   Browser
             CI         Cron
             Terminal

L’écosystème npm a tiré sa puissance de la combinaison de milliers de petits packages, mais cette puissance s’accompagne de coûts en termes de dépendances, de configuration, de travail de compatibilité, de mises à jour de sécurité et d’outils fragmentés. Bun mise sur l’approche inverse : intégrer des primitives utiles directement dans l’environnement d’exécution.

Points clés

• La question pertinente est passée de « Bun est-il plus rapide que Node.js ? » à « quelles parties de mon stack Bun peut-il remplacer ? »
• Les fonctions intégrées réduisent les dépendances natives, mais vérifiez l’équivalence des fonctionnalités avant de remplacer des bibliothèques éprouvées comme sharp ou Playwright.
• Sanitisez la sortie HTML générée par Bun.markdown chaque fois que les données d’entrée ne sont pas fiables.
• Les scripts et tests parallèles apportent des améliorations rapides, mais ils mettent en évidence des problèmes de sérialisation et d’état partagé.
• Considérez les benchmarks des fournisseurs comme une hypothèse et validez chaque fonctionnalité en fonction de vos propres charges de travail avant de l’intégrer.