Bun vs Deno
Bun (runtime Zig, environ 3x plus rapide) face à Deno (runtime Rust, TypeScript en priorité) — comparaison des alternatives modernes à Node.js. Performance, compatibilité, écosystème.
Store adressable par contenu, isolation stricte, audit de chaîne d'approvisionnement mature
Composant d'installation du runtime Bun, au cœur Rust, rapide et tout-en-un
Il n'y a pas de gagnant absolu ; les deux outils optimisent des priorités différentes. Choisis pnpm si tu veux rester indépendant du runtime et auditer la politique à chaque commande modifiant le lockfile. bun install est séduisant si tu utilises déjà Bun comme runtime et que le gain disque/vitesse du global virtual store est critique. Les deux bloquent postinstall par défaut ; la différence se situe dans l'emplacement des points de contrôle. Ne mélange pas les deux dans le même dépôt — un seul lockfile, une seule source de vérité.
| Catégorie | pnpm | bun install |
|---|---|---|
| Performance | 8/10 | 9/10 |
| Facilité d'apprentissage | 7/10 | 8/10 |
| Écosystème | 9/10 | 6/10 |
| Communauté | 8/10 | 7/10 |
| Marché de l'emploi | 7/10 | 6/10 |
| Pérennité | 8/10 | 8/10 |
// pnpm 12.3 — installation contrôlée avec allowBuilds et filtrage de workspace
// package.json (racine)
{
"name": "monorepo-root",
"private": true,
"packageManager": "[email protected]"
}
// pnpm-workspace.yaml — allowBuilds est arrivé en v10.26.0 ; la v11 a supprimé les anciens noms (onlyBuiltDependencies, etc.)
packages:
- "apps/*"
- "packages/*"
allowBuilds:
esbuild: true
sharp: true
core-js: false
catalog:
react: ^19.2.3
typescript: ^5.7.0
// Étape d'installation CI (GitHub Actions)
- name: Install dependencies
run: pnpm install --frozen-lockfile --trust-policy=no-downgrade
// Lors de la suppression d'un paquet, tout le lockfile est revalidé face aux politiques actives
pnpm remove left-pad --filter ./apps/web --trust-lockfile
// Installation uniquement pour les paquets workspace modifiés
pnpm install --filter "...[origin/main]"
// Ajouter l'emplacement du store à la clé de cache CI
pnpm store path// Bun 1.4 — isolated installs + global virtual store + installation offline
// bunfig.toml (racine)
[install]
linker = "isolated"
globalStore = true
exact = false
// package.json
{
"name": "monorepo-root",
"private": true,
"workspaces": ["apps/*", "packages/*"],
"trustedDependencies": [
"esbuild",
"sharp",
"@prisma/client"
]
}
// Étape d'installation CI (GitHub Actions) — verrouillée et compatible offline
- name: Install dependencies
run: bun install --frozen-lockfile --prefer-offline
// Voir les scripts postinstall bloqués
bun pm untrusted
// Marquer un paquet comme fiable
bun pm trust sharp
// Installation pour des paquets workspace spécifiques
bun install --filter "./apps/web"
// Installation entièrement offline (aucun accès réseau)
bun install --offlineIl n'y a pas de gagnant absolu ; les deux outils optimisent des priorités différentes. Choisis pnpm si tu veux rester indépendant du runtime et auditer la politique à chaque commande modifiant le lockfile. bun install est séduisant si tu utilises déjà Bun comme runtime et que le gain disque/vitesse du global virtual store est critique. Les deux bloquent postinstall par défaut ; la différence se situe dans l'emplacement des points de contrôle. Ne mélange pas les deux dans le même dépôt — un seul lockfile, une seule source de vérité.
Obtenir une consultation gratuiteCela dépend du scénario. La mesure publiée par Bun compare ses propres linkers entre eux : sur une fixture React/webpack/Babel/jest de 1 400 paquets, l'installation à chaud est de 823,9 ms avec le linker hoisted contre 124,8 ms avec le linker isolated + global store (Apple Silicon macOS, hyperfine). Le store adressable par contenu de pnpm repose lui aussi sur une lecture disque pour les installations à chaud, donc les deux sont rapides dans les bonnes conditions. Il faut mesurer la différence entre les deux outils sur la taille de ton propre dépôt et ta stratégie de cache CI — ne transpose pas le résultat d'une seule fixture à ton monorepo.