Premiers pas avec vlt, une alternative à npm

vlt est un gestionnaire de paquets JavaScript gratuit et open source, conçu par des personnes qui ont créé et maintenu npm.

vlt est devenu une option sérieuse avec la sortie de la version 1.0. Il installe à partir du package.json, sépare l’installation en une étape de téléchargement et une étape d’exécution des scripts, et propose un langage de requête pour interroger votre graphe de dépendances. Les difficultés se nichent dans les détails : lockfiles, authentification via .npmrc, scripts postinstall et, surtout, le registre d’où proviennent vos paquets. Ce guide passe en revue tous ces points sur un projet existant et se conclut par un verdict clair.

Qu’est-ce que le gestionnaire de paquets vlt et qui l’a créé ?

vlt est un client de gestion de paquets associé à un service de registre hébergé, développé par des personnes à l’origine de npm. L’article de lancement de novembre 2024, signé par Darcy Clarke, Ruy Adorno et Luke Karrys, le présentait comme gratuit et open source. vlt 1.0 est sorti le 4 août 2026, et plusieurs versions 1.x ont suivi depuis.

La CLI de vlt paraîtra familière aux utilisateurs de npm, mais son architecture est différente. Si vous le comparez à l’autre grande alternative à npm, consultez la façon dont pnpm aborde les mêmes problématiques.

Installer vlt et l’exécuter sur un projet existant

Vous pouvez installer vlt via le script officiel ou via npm. Ensuite, vlt install récupère vos dépendances et vlt build exécute leurs scripts.

# official installer, then configure a registry and account
curl -fsSL https://install.vlt.sh | bash
vlt setup

# or install through npm
npm install -g vlt

cd your-project
vlt install   # resolve, download, extract; no dependency scripts run
vlt build     # run lifecycle scripts for eligible packages

L’installation via npm est mentionnée dans le guide de migration depuis npm. Un registre doit être configuré avant que vlt install puisse s’exécuter. La documentation de configuration indique que vlt n’est livré avec aucun registre par défaut : toute commande devant contacter un registre s’interrompt avec une erreur de configuration tant que vous n’en avez pas défini un.

Vous manipulerez deux fichiers à la racine du projet :

• vlt.json : la configuration du projet, qui remplace .npmrc.
• vlt-lock.json : le lockfile de vlt.

Selon le guide de migration depuis npm, vlt ne lit pas package-lock.json et résout tout à partir de zéro. Vous pouvez supprimer l’ancien lockfile, ou le conserver tant que les deux outils cohabitent. Cette approche est moins souple que l’import de lockfile proposé par pnpm, abordé dans passer de npm à pnpm. Comparez les versions résolues avant de fusionner quoi que ce soit.

vlt est-il un remplacement direct (drop-in) ?

Considérez le caractère « drop-in » comme une hypothèse à tester, et non comme un acquis. L’article de lancement de 2024 affirmait que vlt pouvait remplacer votre gestionnaire de paquets actuel « dans la plupart des cas ». L’article de la version 1.0 va plus loin et qualifie le client de remplacement direct de npm. Ces deux affirmations émanent de l’éditeur. Vérifiez ces cinq points sur votre propre projet :

1. Paramètres .npmrc. La documentation n’indique pas que vlt lit .npmrc. Les paramètres de registre et de scope doivent figurer dans vlt.json, sous scoped-registries. Les jetons d’authentification se placent dans le fichier de trousseau (keychain) de vlt ou dans des variables d’environnement VLT_TOKEN, comme décrit dans le guide de migration depuis npm. C’est généralement au niveau des scopes privés qu’une migration casse en premier.
2. Paquets dotés de scripts d’installation. Les addons natifs et les paquets qui téléchargent un binaire ne fonctionneront pas tant que vlt build n’aura pas été exécuté (voir ci-dessous).
3. Peer dependencies. La documentation d’installation précise que vlt vise à conserver une seule copie de chaque peer dependency. Si deux parties de l’arbre requièrent des versions de peer incompatibles, vlt attribue à chacune son propre contexte de peer. Des arbres qui échouent avec l’erreur ERESOLVE de npm peuvent donc se résoudre avec vlt, éventuellement avec plusieurs copies du peer.
4. Workspaces. Les monorepos disposent d’une page dédiée dans la documentation de vlt. Vérifiez la compatibilité de votre structure.
5. CI. Utilisez vlt ci suivi de vlt build.

Une régression due à un changement de gestionnaire de paquets peut passer la CI et n’apparaître qu’en production. Une version transitive différente, ou un script postinstall non exécuté qui aurait dû générer un fichier, peut se manifester sous forme d’erreur d’exécution dans le navigateur. Le session replay, avec capture de la console et du réseau, permet de relier cette erreur au déploiement qui a modifié le lockfile.

Le registre : d’où proviennent vos paquets

Le client vlt n’a pas de registre par défaut : c’est à vous de le choisir. La documentation sur les registres indique que les commandes d’installation (vlt install, vlt ci, vlx, etc.) exigent que l’alias de registre npm soit défini. Une simple valeur registry provenant de vlt.json, d’un flag ou de VLT_REGISTRY ne leur suffit pas. L’autre option consiste à exécuter vlt setup, qui configure les registres de votre compte vlt.io.

L’exécution de vlt setup modifie la source de vos paquets : l’alias npm pointe alors vers le miroir de votre compte sur le registre de vlt. La page d’accueil de vlt précise que chaque requête portant sur un paquet public fait l’objet d’un contrôle de sécurité sur ce miroir, qui bloque les malwares connus. Votre racine de confiance passe ainsi de npm à vlt.

Pour utiliser directement le registre public npm, exécutez :

vlt config set registries=npm=https://registry.npmjs.org/

Exécutée dans le projet, cette commande écrit l’alias dans le vlt.json du projet. Commitez ce fichier pour que toute l’équipe et la CI utilisent la même source.

Une réserve toutefois : un ticket ouvert en avril 2026 signale que vlt install continue d’utiliser les URL de registre enregistrées dans un vlt-lock.json existant. Si vous changez de registre, régénérez le lockfile.

Le blocage au niveau du registre n’arrête que les malwares déjà identifiés. Une version malveillante fraîchement publiée peut passer entre les mailles du filet jusqu’à ce qu’elle soit signalée. Les équipes qui ont besoin d’un hébergement privé peuvent également auto-héberger vsr, le registre de vlt compatible npm et distribué sous licence Fair Source, que l’article de lancement propose en usage local, auto-hébergé ou managé.

Sécurité par défaut : installations en plusieurs phases et vlt build

vlt install n’exécute aucun script de dépendance. vlt build exécute ensuite les scripts de cycle de vie de tous les paquets qui en possèdent, à l’exception de ceux faisant l’objet d’alertes de malware connues, sauf si vous restreignez la cible à l’aide d’un sélecteur. La documentation de build indique la cible par défaut suivante :

:scripts:not(:built):not(:malware)

Il n’y a pas d’invite de validation. Vous approuvez les scripts en écrivant une requête Dependency Selector Syntax plus restrictive. Passez-la comme cible de build, ou utilisez --allow-scripts lors de l’installation, et enregistrez-la dans vlt.json afin que toute l’équipe utilise la même. L’annonce de vlt build détaille ce modèle.

Concrètement, avec les installations en plusieurs phases, un paquet qui a besoin d’un script postinstall pour récupérer un binaire précompilé ou compiler un addon natif n’est pas construit après vlt install. Tout ce qui dépend de son binaire ou de ses fichiers générés peut échouer tant que vlt build n’a pas été exécuté. Ajoutez vlt build à chaque script de configuration et à chaque job de CI.

Le principe rejoint celui de la désactivation par défaut des scripts d’installation npm. Cependant, les contrôles côté consommateur ne protègent que les installations. Côté publication, vérifiez le contenu de vos paquets avec npm pack --dry-run pour éviter de publier des fichiers par inadvertance.

Requêtes sur le graphe de dépendances avec vlt query

vlt query sélectionne des paquets dans votre graphe de dépendances résolu à l’aide de sélecteurs de type CSS, de la même manière que querySelectorAll sélectionne des éléments dans une page. L’article de la version 1.0 dénombre plus de 60 pseudo-sélecteurs de graphe, dont une trentaine dédiés à la sécurité. L’article de vlt sur les sélecteurs insights précise que les sélecteurs de sécurité s’appuient sur les métadonnées de Socket.

vlt query ':scripts'                  # packages with install scripts
vlt query ':malware'                  # packages with known malware alerts
vlt query ':prod'                     # production dependencies only
vlt query ':scripts' --view=mermaid   # render matches as a Mermaid diagram

La documentation de query répertorie les modes de sortie : human, json, mermaid, svg, png et count. Commencez par :scripts, car c’est dans cette liste que vlt build puise par défaut (en ignorant ensuite les paquets déjà construits et ceux faisant l’objet d’alertes de malware). D’après l’article de vlt sur le host context, :host(local) exécute une requête sur l’ensemble des projets configurés dans le tableau de bord de vlt.

Les mêmes sélecteurs fonctionnent en CI :

- run: npm install -g vlt
- run: vlt ci          # vlt install --expect-lockfile
- run: vlt build
- name: Report dependencies with malware alerts
  run: vlt query ':malware' --view=count

Pour que cette dernière étape fasse échouer le job, ajoutez --expect-results=0, option décrite dans la documentation de query. La requête reste identique partout : elle constitue votre politique, stockée sous forme d’une simple chaîne de sélecteur.

Verdict : à tester sur un projet annexe, pas encore à adopter par défaut

vlt mérite dès maintenant d’être essayé sur un projet annexe. Une équipe en production devrait conserver son gestionnaire de paquets actuel jusqu’à ce que sa propre CI, l’authentification à son registre privé et ses paquets dotés de scripts d’installation fonctionnent tous correctement avec vlt. Les installations en plusieurs phases et vlt query sont utiles. La résolution complète du lockfile et le choix du registre exigent en revanche une décision réfléchie. Si la vitesse d’installation est votre priorité, comparez avec la réécriture en Rust de pnpm 12 sur votre propre dépôt.

Commencez sur une branche. Définissez explicitement l’alias de registre npm, exécutez vlt install, vlt build et vlt query ':scripts', puis comparez les versions résolues dans vlt-lock.json avec celles de votre ancien lockfile avant que quoi que ce soit n’atteigne la branche main.

FAQ

Quelle version de Node.js vlt requiert-il, et crée-t-il toujours un dossier node_modules ?

Le paquet vlt requiert Node.js 22.22 ou une version ultérieure. vlt crée toujours un répertoire node_modules, mais il y utilise sa propre organisation interne, sous node_modules/.vlt/, différente de l'arborescence à plat de npm. Par défaut, vlt crée des liens physiques (hard links) vers les fichiers d'un store global sous Linux, et décompresse chaque paquet sous macOS et Windows ; le paramètre store-linker permet de modifier ce comportement. Les paquets se résolvent normalement à l'exécution : le code de votre application ne devrait donc pas avoir besoin d'être modifié.

Qu'est-ce qui remplace npx et npm run avec vlt ?

vlt exec remplace npx. Vous pouvez également l'appeler via vlt x ou avec le raccourci vlx. Cette commande exécute le binaire d'un paquet et télécharge celui-ci s'il ne se trouve pas dans node_modules, en demandant confirmation avant de récupérer tout nouvel élément. vlxl n'exécute que les binaires déjà installés. vlt run, abrégé en vlr, exécute les scripts du package.json avec leurs hooks pre et post. Les deux acceptent un sélecteur --scope pour cibler des workspaces.

Comment migrer les overrides npm vers vlt ?

L'équivalent dans vlt du champ overrides de npm s'appelle les Graph Modifiers. Vous les définissez dans vlt.json et les rédigez sous forme de requêtes Dependency Selector Syntax. Cela permet de cibler une dépendance par chemin, par workspace ou par plage semver, et pas seulement par nom de paquet. Lorsque plusieurs modificateurs correspondent à la même dépendance, vlt applique des règles de spécificité inspirées de CSS pour déterminer lequel l'emporte.

Comment configurer les workspaces dans un monorepo vlt ?

vlt lit tel quel le champ workspaces du package.json racine : un monorepo npm ou yarn existant fonctionne donc sans modification. Utilisez le champ workspaces du vlt.json racine si vous souhaitez définir des groupes nommés ou si vous migrez depuis pnpm-workspace.yaml. Si vlt.json contient un champ workspaces, vlt utilise uniquement celui-ci et ignore le champ du package.json ; les deux ne sont pas fusionnés. Dans vlt.json, la valeur peut être une chaîne glob, un tableau de globs comme packages/*, ou un objet de groupes nommés associant chacun des chemins ou des globs. Un simple tableau est placé dans le groupe par défaut, nommé packages.