Comment réduire le temps d'installation des paquets de 28 minutes à 47 secondes avec Bun
makedream8 de maio de 2026
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Dans un environnement Node.js, on a souvent l'impression de passer plus de temps à regarder des barres de progression qu'à coder, tout en luttant contre des montagnes de dépendances. Bun ne se contente pas d'être un runtime rapide ; il prépare un terrain de jeu idéal pour collaborer avec des agents IA. Derrière l'argument superficiel de la vitesse, discutons des méthodes de migration pragmatiques et de la conception architecturale.
Bun a été réécrit de zéro en langage Zig. Grâce à cela, l'installation des paquets est incroyablement plus rapide que sur Node.js v22. Cependant, si vous mélangez Bun tout en conservant l'ancien package-lock.json, les fichiers de verrouillage vont s'emmêler et vos machines de déploiement vont commencer à hurler. Dans ce cas, n'essayez pas de les faire cohabiter maladroitement ; il faut repartir sur de nouvelles bases.
Tout d'abord, supprimez courageusement node_modules et votre ancien fichier de verrouillage. Ensuite, exécutez bun install --frozen-lockfile dans votre terminal pour générer le bun.lockb, le fichier de verrouillage binaire propre à Bun. Pour les bibliothèques comme bcrypt qui utilisent des extensions C++ et génèrent des erreurs de compilation, il est préférable pour votre santé mentale de passer à bcryptjs ou d'utiliser l'API native de Bun, bun:sqlite. Passer de 28 minutes à 47 secondes pour un projet comptant plus de 1 800 dépendances est une expérience assez grisante.
Si vous donnez des fichiers de plusieurs milliers de lignes à un agent IA basé sur LLM, il perdra rapidement le fil et commencera à divaguer. Bun est si rapide pour les entrées/sorties (I/O) de fichiers qu'il n'y a presque aucune perte de performance même si vous fragmentez énormément vos fichiers. Pour augmenter la précision de l'agent lorsqu'il modifie le code, il est avantageux de maintenir une structure de moins de 100 lignes par fichier.
Personnellement, je crée des dossiers comme src/agents et src/tools pour séparer complètement les fonctionnalités au sein du projet. Ensuite, je combine Bun.serve et Bun.file pour construire une passerelle qui ne permet de manipuler que des répertoires spécifiques. En vérifiant les chemins avec targetPath.startsWith, on évite que l'agent n'aille fouiller dans les paramètres système de mon MacBook. C'est une structure qui garantit la sécurité tout en économisant des jetons (tokens).
Lorsqu'un agent IA appelle un outil et que la réponse met une éternité à arriver, l'expérience utilisateur est gâchée. Express ralentit lorsque le nombre de requêtes augmente, car il parcourt les routes de manière séquentielle. En revanche, Hono utilise l'algorithme Trie pour trouver immédiatement le chemin correspondant.
En combinant Bun et Hono, le débit de requêtes par seconde (RPS) grimpe jusqu'à environ 41 800. C'est plus de trois fois plus rapide qu'Express. Commencez par bun add hono et lisez vos variables d'environnement directement avec Bun.env. En y ajoutant l'API WebSocket haute performance de Bun, vous pouvez maintenir la latence des réponses en temps réel autour de 27ms. Plus besoin de voir l'IA attendre bêtement à cause d'un serveur léthargique.
Utiliser Bun seul ne suffit pas. Toute l'équipe doit utiliser le même environnement pour éviter les incidents en production. Placez un fichier .bunfig.toml à la racine pour fixer les informations du registre privé ou les options du fichier de verrouillage. Cela réduit le temps d'installation pour les nouveaux membres de l'équipe.
Lors du déploiement, portez une attention particulière à la taille de l'image Docker. Utilisez l'image oven/bun:1 comme base, mais profitez de l'option bun build --compile pour transformer votre code source en un fichier exécutable unique. En extrayant seulement ce fichier pour le placer dans une image distroless, une image Node.js qui dépassait 1 Go peut être réduite à moins de 200 Mo. Réduire la taille de l'image diminue les coûts d'infrastructure cloud d'environ 40 %, il n'y a donc aucune raison de s'en priver.