Qu'est-ce qu'Aube, le gestionnaire de paquets Node.js le plus rapide en 2026 ?

Les installations Node sont lentes depuis des années. Vous lancez npm install, allez à la machine à café, revenez, et la CI est toujours en train de résoudre @types/node. Aube change cette équation. Il termine une installation CI à chaud d'un projet réel de 1 400 paquets en 139 millisecondes, ce qui est environ 7,3 fois plus rapide que pnpm et 3 fois plus rapide que Bun sur la même configuration. Le plus intéressant : il lit et écrit votre fichier de verrouillage (lockfile) existant, vous pouvez donc l'essayer dès lundi sans demander à quiconque de migrer.

Ce guide explique ce qu'est Aube, comment il atteint ces performances, comment l'installer, comment il se compare à pnpm, npm, yarn et Bun, et où il s'intègre si vous développez quotidiennement des API avec des outils comme Apidog.

Qu'est-ce qu'Aube ?

Aube est un gestionnaire de paquets Node.js rapide, développé par en.dev et publié sous licence MIT. Son nom signifie « aube » en français et se prononce « ob ». Le projet est en version bêta (v1.0.0-beta.10 au moment de la rédaction) et vise la compatibilité avec pnpm v11 comme objectif principal.

L'idée est simple. Aube utilise le même modèle de stockage sur disque que pnpm, un magasin global adressable par contenu (content-addressable store) plus une disposition de liens symboliques (symlink layout) isolée, mais le pipeline d'installation est écrit dans un langage avec gestion native des threads au lieu de JavaScript. Même disposition, moteur plus rapide. Ce choix de conception unique lui permet de surpasser Bun dans plusieurs scénarios de benchmark, tout en écrivant pnpm-lock.yaml à sa place.

Si vous avez déjà migré entre des gestionnaires de paquets, vous savez que le véritable coût n'est pas l'outil, mais le coût social de devoir faire changer toute votre équipe sa façon d'exécuter install. Aube contourne cela en lisant directement pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock et bun.lock. Vous pouvez l'exécuter localement pendant que votre CI utilise toujours pnpm, et rien ne change pour vos coéquipiers.

Benchmarks Aube : quelle est la vitesse du « plus rapide » ?

Le banc d'essai est un projet réel d'environ 1 400 paquets mesuré avec hyperfine. Chaque scénario suppose un fichier de verrouillage (lockfile) validé. L'axe qui varie est la chaleur du cache : *chaud* efface node_modules mais conserve le magasin global et le cache de packuments, *froid* efface tout.

Chiffres des benchmarks officiels (aube 1.0.0-beta.3, bun 1.3.12, pnpm 10.33.0, npm 11.12.1, yarn 1.22.22, node 24.15.0) :

Quelques points se distinguent. L'installation CI à chaud est le chiffre phare car elle reflète le cas le plus courant dans les pipelines réels, où le runner restaure un cache et votre magasin global contient toujours chaque tarball haché. Dans ce scénario, Aube est environ 7,3 fois plus rapide que pnpm et 3 fois plus rapide que Bun.

Le scénario install && run test mesure la boucle de développement quotidienne. Chaque outil doit décider « dois-je d'abord installer, puis exécuter le script ? ». Aube peut entièrement ignorer le travail d'installation lorsque son fichier d'état d'installation est à jour, de sorte que la boucle install && test complète revient en 21 ms. Les autres outils revalident toujours le fichier de verrouillage avant de lancer le script, ce qui explique le surcoût de 400ms-600ms.

Sur un cache froid, Bun devance Aube (935 ms contre 1,12 s) car le chemin de récupération des tarball de Bun est extrêmement bien optimisé et les installations à froid sont dominées par les E/S. Le scénario chaud est celui qui s'exécute des milliers de fois par jour dans une équipe de développement typique ; le froid s'exécute une fois par mois lorsque vous effacez un runner.

Sur l'ensemble complet des bancs d'essai, la documentation indique des pics allant jusqu'à 22 fois plus rapide que pnpm et jusqu'à 3 fois plus rapide que Bun, selon le scénario. Vous pouvez reproduire tout cela localement avec mise run bench depuis le dépôt Aube.

Pourquoi Aube est plus rapide que pnpm et Bun

Trois choix de conception sont à l'origine de ces performances.

Pipeline d'installation natif et multithreadé. npm, pnpm et yarn exécutent tous le moteur d'installation dans Node.js. Cela signifie que chaque hachage, chaque extraction de tarball, chaque appel de lien symbolique paie le coût de l'appel JavaScript. Aube déplace le chemin critique (hot path) de V8 vers un environnement d'exécution compilé nativement et gérant les threads de manière native. Bun fait quelque chose de similaire mais fournit un environnement d'exécution JavaScript complet avec son gestionnaire de paquets ; Aube est conçu spécifiquement pour le chemin d'installation, ce qui explique en partie pourquoi il surpasse Bun sur les installations à chaud.

Le magasin virtuel global est le défaut. pnpm v11 a ajouté enableGlobalVirtualStore, mais ce n'est pas le comportement par défaut pour les installations de projets. Aube utilise par défaut un magasin virtuel global, de sorte que les projets répétitifs avec des dépendances qui se chevauchent sont la plupart du temps liés à des arborescences de paquets qui existent déjà sur le disque. Si vous avez trois services qui utilisent tous React, Vite, TypeScript et Playwright, les fichiers volumineux résident à un seul endroit et chaque projet y crée un lien symbolique. La documentation estime une réduction d'environ 90% de l'espace disque par rapport à npm dans les configurations de monorepos typiques.

Court-circuitage de l'installation avec un fichier d'état à jour. aube run test vérifie d'abord un fichier d'état d'installation compact. Si le hachage de votre package.json et de votre fichier de verrouillage correspond au fichier d'état, la phase d'installation est un simple appel stat et le test est lancé immédiatement. C'est ce qui ramène le chiffre de install && test à 21 ms.

Rien de tout cela n'est magique. C'est le résultat lorsque vous prenez la structure de pnpm, retirez le bootstrapping JavaScript, et concevez l'interface en ligne de commande en partant du principe que 99 % des installations sont des cas où « rien n'a réellement changé ».

Comment installer Aube

Le chemin recommandé est mise, le gestionnaire d'outils polyglotte :

mise use -g aube

Vérifiez qu'il est bien sur votre PATH :

aube --version

Si vous préférez npm :

npm install -g @endevco/aube

Sur macOS ou Linux avec Homebrew, le tap Endev le propose :

brew install endevco/tap/aube

Dans un projet, vous pouvez épingler la version d'Aube localement :

mise use aube

Cela enregistre aube comme un outil dans votre mise.toml, ce qui signifie que chaque shell qui entre dans le dossier du projet obtient la même version. Fini le « ça marche sur ma machine parce que j'ai installé pnpm 10 l'année dernière ». La documentation d'installation couvre également les options tarball et par OS.

Commandes quotidiennes que vous utiliserez réellement

L'interface des commandes est très similaire à celle de pnpm, ce qui facilite le transfert de la mémoire musculaire :

aube install              # installe les dépendances
aube add react            # ajoute une dépendance
aube add -D vitest        # ajoute une dépendance de développement
aube remove react         # supprime une dépendance
aube update               # met à jour dans les plages définies par package.json
aube run build            # exécute un script package.json
aube test                 # exécute le script de test, installe d'abord si obsolète
aube exec vitest          # exécute un binaire local
aube dlx cowsay hi        # exécute un paquet dans un environnement jetable
aube ci                   # installation propre et figée pour la CI

Vous pouvez raccourcir la plupart d'entre elles. Si le script existe dans package.json, aube dev est identique à aube run dev. Il existe également deux shims multicall livrés dans le même binaire :

aubr build       # aube run build
aubx cowsay hi   # aube dlx cowsay hi

Utilisez aube ci dans les pipelines. Il supprime node_modules, confirme que le fichier de verrouillage (lockfile) est à jour pour le package.json actuel, puis installe. Si le fichier de verrouillage a divergé, il échoue bruyamment, ce qui est souhaitable en CI.

Compatibilité du lockfile

C'est la fonctionnalité qui fait d'Aube une adoption à faible risque. Vous n'avez pas besoin de vous engager à faire changer toute l'équipe.

Le schéma pratique ressemble à ceci. Votre équipe utilise pnpm. La CI exécute toujours pnpm install --frozen-lockfile. Vous exécutez aube install localement sur votre machine. Il lit pnpm-lock.yaml, produit la même structure node_modules et réécrit toutes les mises à jour de résolution dans le même pnpm-lock.yaml. Un coéquipier tire votre branche, exécute pnpm install, et rien n'est anormal. Avec le temps, si Aube fait ses preuves, vous migrez la CI. Si ce n'est pas le cas, vous l'arrachez et personne en aval ne le saura.

Deux mises en garde. Les anciens lockfiles pnpm v5 ou v6 doivent d'abord être mis à jour avec pnpm. Et les projets yarn PnP (du style `.pnp.cjs`) doivent revenir à un lieur node_modules car Aube écrit node_modules, et non des artefacts PnP.

Les valeurs par défaut sécurisées sont plus importantes que vous ne le pensez

Si vous avez été en contact avec une base de code JavaScript au cours des 18 derniers mois, vous avez vu les incidents de chaîne d'approvisionnement s'accumuler. Le guide de sécurité de la chaîne d'approvisionnement npm décrit le modèle ; la compromission npm d'Axios a été l'un des cas réels les plus clairs de la façon dont une seule dépendance populaire peut envoyer un RAT (cheval de Troie d'accès à distance) multiplateforme à des milliers de machines de développeurs.

Aube adopte trois valeurs par défaut affirmées qui considèrent les installations comme une frontière de sécurité, et non comme une commodité :

1. Âge minimal de publication. Les nouvelles versions attendent un âge minimal configurable avant qu'Aube ne les installe. Un paquet fraîchement compromis qui est retiré en deux heures ne touche jamais votre node_modules.
2. Blocage des dépendances exotiques. Aube bloque les dépendances transitives dont la forme semble suspecte (URL inhabituelles, entrées de type patch, références Git à des endroits qui contiennent normalement du semver). Si vous en voulez une explicitement, vous l'approuvez.
3. Approbation des scripts de cycle de vie. Les scripts postinstall des dépendances sont ignorés par défaut. Vous exécutez aube approve-builds pour autoriser des paquets spécifiques (esbuild, node-sass, tout ce dont vous avez réellement besoin pour construire localement). Les paquets dont les scripts ont été ignorés apparaissent dans aube ignored-builds.

Ces trois comportements ne vous rendent pas invulnérable, mais ils transforment « je ne savais même pas que ce paquet exécutait du code » en « j'ai choisi de laisser ce paquet exécuter du code ». C'est la posture de sécurité que vous souhaitez avant votre prochain incident de production.

Disposition des modules Node

Aube utilise une disposition isolée de node_modules. Le node_modules/ de premier niveau contient les dépendances déclarées dans votre package.json. Les dépendances transitives se trouvent derrière node_modules/.aube/. Les fichiers des paquets sont stockés une seule fois à l'emplacement $XDG_DATA_HOME/aube/store/, qui par défaut est ~/.local/share/aube/store/.

Trois conséquences :

• Plusieurs projets avec des dépendances qui se chevauchent partagent les fichiers de paquets sur le disque. Fini le « j'ai 12 copies de lodash réparties dans mon monorepo et mes projets secondaires ».
• Les dépendances fantômes sont plus difficiles à utiliser. Si un paquet n'est pas dans votre package.json, vous ne pouvez pas l'appeler via require depuis le niveau supérieur, car il ne se trouve pas dans node_modules/. C'est la même garantie que pnpm vous offre.
• Les installations répétées réutilisent les fichiers déjà présents sur le disque. Le seul travail restant est de créer des liens physiques (hard-linking) depuis le magasin vers le nouveau node_modules/.aube/.

Si vous utilisiez auparavant une disposition node_modules plate (npm classique ou yarn v1), attendez-vous à trouver un ou deux paquets cassés qui dépendaient d'imports fantômes. La solution est toujours « ajoutez-le à votre package.json ».

Workspaces et monorepos

Aube prend en charge les workspaces et le protocole workspace: :

aube install -r
aube run test -r
aube add zod --filter @acme/api

Si votre dépôt contient déjà pnpm-workspace.yaml, Aube le lit et l'écrit. Les nouveaux workspaces privilégiant Aube utilisent aube-workspace.yaml. Les drapeaux -r (récursif) et --filter correspondent aux mêmes sémantiques que celles attendues de pnpm, de sorte que les configurations turborepo et nx continuent de fonctionner sans modification.

Pour les monorepos d'API, le chiffre de la CI en cache chaud est le plus important. Si votre pipeline effectue install, build, test, publish contract à chaque fusion, réduire le temps d'`install` de 1 seconde avec pnpm à 139 millisecondes avec Aube sur dix paquets représente des minutes réelles par jour.

Où Aube s'intègre dans un flux de travail de développement d'API

Si vous construisez et testez des API, les installations se situent sur le chemin critique de chaque refactorisation. Vous modifiez un schéma de requête, régénérez le client TypeScript, réinstallez, exécutez des tests de contrat contre votre serveur de maquette, et répétez. Une installation rapide n'est pas une métrique de vanité ; c'est l'intervalle entre « j'ai changé ceci » et « je sais si cela a cassé quelque chose ».

Une boucle pratique qui fonctionne bien :

1. Concevez et maquettez l'API dans Apidog. L'approche « schema-first » est supérieure à l'approche « code-first » pour tout ce qui interagit avec une autre équipe.
2. Générez un client typé (ou exécutez des tests de contrat contre la maquette Apidog) au sein de votre projet Node.
3. Utilisez Aube localement pour maintenir les installations dans la plage des millisecondes pendant que vous itérez sur le client.
4. Connectez la même suite de tests à la CI avec aube ci.

Le changement d'outillage s'éloignant de Postman au cours de la dernière année fait partie d'un modèle plus large : les développeurs veulent des outils rapides, axés sur le local et sécurisés par défaut. Aube est la même histoire appliquée à l'étape d'installation. Si vous utilisez déjà Apidog dans VS Code, l'ajout d'Aube à côté ne vous coûte qu'une ligne mise use et vous fait gagner des secondes à chaque rechargement à chaud.

Migration depuis chaque gestionnaire de paquets

Depuis npm. Exécutez aube install dans le projet. Aube lit package-lock.json et le réécrit. Vous obtenez des node_modules isolés au lieu d'une structure plate, soyez donc attentif aux imports fantômes. Si l'un d'eux se casse, ajoutez le paquet manquant à package.json et continuez. Flux de travail complet dans le guide pour les utilisateurs de npm.

Depuis pnpm. C'est la migration la moins contraignante car la disposition sur disque est la même. Aube lit directement pnpm-lock.yaml v9. Le protocole workspace: fonctionne. Les filtres fonctionnent. La page pnpm-users répertorie les quelques drapeaux qui se comportent différemment.

Depuis yarn. Aube lit les lockfiles de la v1 classique et de la v2+ berry. Les utilisateurs de Yarn PnP doivent revenir au mode nodeLinker: node-modules avant d'essayer Aube, car Aube écrit node_modules et non `.pnp.cjs`.

Depuis Bun. Aube lit bun.lock. La principale différence est que le gestionnaire de paquets de Bun est étroitement lié à l'environnement d'exécution JS de Bun ; Aube est un outil d'installation autonome qui fonctionne avec n'importe quelle version de Node.js. Si vous utilisez déjà mise pour la gestion des versions de Node, Aube s'intègre de la même manière.

Considérations pratiques

Statut bêta. En avril 2026, Aube est en version v1.0.0-beta.10. La documentation est explicite : il vise la compatibilité pnpm v11, mais il n'a pas encore été testé sur de nombreux projets. Traitez-le comme vous le feriez pour tout outil pré-1.0. Exécutez-le localement d'abord, conservez votre lockfile existant, ne pariez pas votre pipeline de publication en production dessus tant que vous ne l'avez pas vu fonctionner pendant un mois.

Ce qui est hors de portée. Aube ne duplique intentionnellement pas ce que mise fait déjà. La gestion de l'environnement d'exécution (env, runtime, setup, self-update) lui appartient. Certains assistants de compte de registre (whoami, token, owner, search, pkg, set-script) sont des stubs de compatibilité qui vous renvoient à la commande npm. Si votre script CI appelle l'un de ceux-ci, gardez npm comme solution de repli.

Support des plateformes. L'installateur recommandé est mise, qui prend en charge macOS, Linux et Windows via WSL. Le support natif de Windows via le tarball existe mais est à un stade plus précoce ; consultez la page d'installation pour la matrice actuelle.

Communauté. Le projet dispose d'un Discord (lié depuis la page d'accueil) et de 325 étoiles sur GitHub au moment de la rédaction. Petite mais active. Buildkite fournit la CI pour le projet, que vous pouvez voir à la racine du dépôt.

FAQ

Que signifie « aube » ?Aube, en français. Se prononce « ob ». Le slogan du projet est « une nouvelle aube pour les installations Node ».

Aube est-il un remplacement direct pour pnpm ?Presque. Il vise la compatibilité pnpm v11 et lit le format de lockfile de pnpm. La plupart des workflows basés sur pnpm se transfèrent sans modifications. Certaines commandes pnpm (gestion de l'environnement d'exécution, quelques assistants de registre) sont intentionnellement hors de portée car elles appartiennent à d'autres outils.

Puis-je utiliser Aube en CI tout en gardant pnpm localement ?Oui, les deux directions fonctionnent. Aube lit et écrit pnpm-lock.yaml sur place, de sorte que les deux outils peuvent partager un lockfile. Les équipes commencent souvent dans l'autre sens : Aube localement, pnpm en CI, jusqu'à ce que tout le monde soit à l'aise.

Comment Aube se compare-t-il à Bun ?Sur les installations à chaud, Aube est environ 3 fois plus rapide que Bun car Bun revalide plus d'état avant d'installer. Sur les installations à froid, Bun est légèrement en avance car son chemin de récupération est extrêmement optimisé. Bun propose également un environnement d'exécution JS ; Aube est uniquement dédié à l'installation. Si vous utilisez déjà Node, vous n'avez pas besoin de l'environnement d'exécution de Bun pour utiliser Aube. La comparaison de la disposition isolée de type pnpm donne un aperçu de l'importance des choix de disposition.

Aube fonctionne-t-il sur Windows ?Via WSL, oui. Le support natif de Windows fonctionne mais est à un stade plus précoce. mise est le moyen le plus simple d'installer et de mettre à jour sur les trois OS.

Aube est-il open source ?Oui, sous licence MIT, code source sur GitHub.

Qu'advient-il de mon pnpm-lock.yaml existant ?Aube le lit, effectue l'installation et réécrit le même fichier avec les éventuels changements de résolution. Vos coéquipiers utilisant pnpm verront une différence de lockfile normale.

En résumé

Pour la plupart des projets Node en 2026, l'étape d'installation est plus lente qu'elle ne devrait l'être. Aube est le gestionnaire de paquets Node.js le plus rapide sur les chemins d'installation à chaud et de commandes répétées qui dominent les flux de travail réels des développeurs : 139 ms pour une installation CI de 1 400 paquets, 21 ms pour install && test lorsque rien n'a changé, 90 % d'espace disque en moins sur une machine avec plusieurs projets. Il lit votre lockfile existant, prend au sérieux les valeurs par défaut de sécurité, et ne coûte qu'un mise use aube pour l'essayer.

Si vous testez déjà des API avec un client rapide et local-first comme Apidog, Aube est la pièce complémentaire du côté de l'installation. Téléchargez Apidog si vous ne l'avez pas encore fait, associez-le à Aube pour votre prochain service Node, et constatez à quel point la boucle de rétroaction est plus rapide.