Erste Schritte mit vlt, einer npm-Alternative

vlt ist ein kostenloser Open-Source-Paketmanager für JavaScript, entwickelt von den Leuten, die npm geschaffen und betreut haben.

Seit Version 1.0 ist vlt eine ernstzunehmende Option. Es installiert anhand der package.json, trennt Installationen in einen Download-Schritt und einen Skript-Schritt und bringt eine Abfragesprache für Ihren Abhängigkeitsgraphen mit. Die Hürden liegen im Detail: Lockfiles, .npmrc-Authentifizierung, Postinstall-Skripte und vor allem die Frage, aus welcher Registry Ihre Pakete stammen. Dieser Leitfaden geht all diese Punkte anhand eines bestehenden Projekts durch und endet mit einem klaren Fazit.

Was ist der vlt-Paketmanager und wer hat ihn entwickelt?

vlt besteht aus einem Paketmanager-Client und einem gehosteten Registry-Dienst und stammt von Entwicklern, die npm gebaut haben. Der Launch-Beitrag vom November 2024, unterzeichnet von Darcy Clarke, Ruy Adorno und Luke Karrys, stellte vlt als kostenlos und quelloffen vor. vlt 1.0 erschien am 4. August 2026, seitdem folgen 1.x-Releases.

Die vlt-CLI wird npm-Nutzern vertraut vorkommen. Die Architektur ist jedoch eine andere. Wenn Sie vlt mit der anderen großen npm-Alternative vergleichen möchten, lesen Sie, wie pnpm dieselben Probleme angeht.

vlt installieren und in einem bestehenden Projekt ausführen

Sie können vlt über das offizielle Skript oder über npm installieren. Danach lädt vlt install Ihre Abhängigkeiten, und vlt build führt deren Skripte aus.

# 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

Der Weg über npm ist im Migrationsleitfaden für npm beschrieben. Bevor vlt install läuft, muss eine Registry konfiguriert sein. Laut der Konfigurationsdokumentation wird vlt ohne Standardwert ausgeliefert, und jeder Befehl, der eine Registry erreichen muss, bricht mit einem Konfigurationsfehler ab, bis Sie eine festlegen.

Im Projektstammverzeichnis arbeiten Sie mit zwei Dateien:

• vlt.json: Projektkonfiguration, übernimmt die Rolle der .npmrc.
• vlt-lock.json: das Lockfile von vlt.

Laut dem Migrationsleitfaden liest vlt keine package-lock.json. Es löst alles von Grund auf neu auf. Sie können das alte Lockfile löschen oder es behalten, solange beide Tools parallel laufen. Das ist weniger behutsam als der Lockfile-Import von pnpm, der in Umstieg von npm auf pnpm behandelt wird. Vergleichen Sie die aufgelösten Versionen per Diff, bevor Sie etwas mergen.

Ist vlt ein Drop-in-Ersatz?

Betrachten Sie „Drop-in“ als etwas, das Sie testen, nicht als etwas, das Sie voraussetzen. Der Launch-Beitrag von 2024 sprach davon, dass vlt Ihren bisherigen Paketmanager „in den meisten Fällen“ ersetzen könne. Der Beitrag zu 1.0 geht weiter und bezeichnet den Client als Drop-in-Ersatz für npm. Beide Aussagen stammen vom Hersteller. Prüfen Sie diese fünf Bereiche in Ihrem eigenen Projekt:

1. .npmrc-Einstellungen. Die Dokumentation erwähnt nicht, dass vlt die .npmrc liest. Registry- und Scope-Einstellungen gehören in die vlt.json unter scoped-registries. Auth-Tokens kommen in die Keychain-Datei von vlt oder in VLT_TOKEN-Umgebungsvariablen, wie im Migrationsleitfaden beschrieben. Private Scopes sind meist die Stelle, an der eine Migration zuerst scheitert.
2. Pakete mit Installationsskripten. Native Addons und Pakete, die ein Binary herunterladen, funktionieren erst, nachdem vlt build gelaufen ist (siehe unten).
3. Peer-Dependencies. Laut der Install-Dokumentation strebt vlt genau eine Kopie jeder Peer-Dependency an. Benötigen zwei Teile des Baums Peer-Versionen, die nicht nebeneinander existieren können, erhält jeder Teil seinen eigenen Peer-Kontext. Bäume, die mit npms ERESOLVE-Fehler scheitern, lassen sich unter vlt möglicherweise auflösen – eventuell mit mehr als einer Kopie des Peers.
4. Workspaces. Für Monorepos gibt es in der vlt-Dokumentation eine eigene Seite. Gleichen Sie Ihre Struktur damit ab.
5. CI. Verwenden Sie vlt ci, gefolgt von vlt build.

Eine Regression, die durch den Wechsel des Paketmanagers entsteht, kann die CI bestehen und erst in Produktion auffallen. Eine andere transitive Version oder ein übersprungenes Postinstall-Skript, das eine Datei hätte erzeugen sollen, kann sich als Laufzeitfehler im Browser zeigen. Session Replay mit Konsolen- und Netzwerkaufzeichnung verknüpft diesen Fehler mit dem Deployment, das das Lockfile geändert hat.

Die Registry: Woher Ihre Pakete stammen

Der vlt-Client hat keine Standard-Registry. Sie wählen eine aus. Laut der Registry-Dokumentation benötigen Installationsbefehle (vlt install, vlt ci, vlx und andere) einen gesetzten Registry-Alias npm. Ein einfacher registry-Wert aus der vlt.json, einem Flag oder VLT_REGISTRY reicht ihnen nicht aus. Der alternative Weg ist vlt setup, das die Registries Ihres vlt.io-Kontos konfiguriert.

Mit vlt setup ändern Sie Ihre Paketquelle. Der Befehl verweist den Alias npm auf den Mirror Ihres Kontos in der vlt-Registry. Laut der vlt-Startseite durchläuft jede Anfrage nach einem öffentlichen Paket auf diesem Mirror eine Sicherheitsprüfung, die bekannte Malware blockiert. Ihr Vertrauensanker verschiebt sich damit von npm zu vlt.

Um die öffentliche npm-Registry direkt zu nutzen, führen Sie Folgendes aus:

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

Innerhalb des Projekts ausgeführt, schreibt dieser Befehl den Alias in die vlt.json des Projekts. Committen Sie diese Datei, damit das gesamte Team und die CI dieselbe Quelle verwenden.

Ein Vorbehalt: Ein im April 2026 eröffnetes Issue berichtet, dass vlt install weiterhin die Registry-URLs verwendet, die in einer bestehenden vlt-lock.json hinterlegt sind. Wenn Sie die Registry wechseln, generieren Sie das Lockfile neu.

Das Blockieren auf Registry-Ebene stoppt nur Malware, die bereits identifiziert wurde. Eine neu veröffentlichte bösartige Version kann weiterhin durchrutschen, bis jemand sie meldet. Teams, die privates Hosting benötigen, können außerdem vsr selbst hosten – die npm-kompatible Fair-Source-Registry von vlt, die laut Launch-Beitrag für den lokalen, selbst gehosteten oder verwalteten Betrieb angeboten wird.

Sicherheitsvorgaben: Phasenweise Installation und vlt build

vlt install führt keine Skripte von Abhängigkeiten aus. Anschließend führt vlt build die Lifecycle-Skripte aller Pakete aus, die welche haben – ausgenommen Pakete mit bekannten Malware-Warnungen –, sofern Sie das Ziel nicht mit einem Selektor eingrenzen. Die Build-Dokumentation nennt als Standardziel:

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

Es gibt keine Bestätigungsabfrage. Skripte genehmigen Sie, indem Sie eine engere Abfrage in der Dependency Selector Syntax schreiben. Übergeben Sie diese als Build-Ziel oder verwenden Sie --allow-scripts bei der Installation, und speichern Sie sie in der vlt.json, damit das gesamte Team dieselbe nutzt. Die Ankündigung von vlt build erläutert das Modell.

In der Praxis bedeutet die phasenweise Installation: Ein Paket, das ein Postinstall-Skript benötigt, um ein vorkompiliertes Binary herunterzuladen oder ein natives Addon zu kompilieren, ist nach vlt install nicht gebaut. Alles, was von seinem Binary oder seinen generierten Dateien abhängt, kann fehlschlagen, bis vlt build läuft. Nehmen Sie vlt build in jedes Setup-Skript und jeden CI-Job auf.

Der Ansatz entspricht dem standardmäßigen Deaktivieren von npm-Installationsskripten. Konsumentenseitige Kontrollen schützen allerdings nur Installationen. Auf der Seite der Veröffentlichung sollten Sie Paketinhalte mit npm pack --dry-run prüfen, damit Sie keine Dateien ausliefern, die Sie nicht ausliefern wollten.

Abfragen des Abhängigkeitsgraphen mit vlt query

vlt query wählt Pakete aus Ihrem aufgelösten Abhängigkeitsgraphen mit CSS-artigen Selektoren aus – ähnlich wie querySelectorAll Elemente einer Seite auswählt. Der Beitrag zu 1.0 zählt mehr als 60 Graph-Pseudo-Selektoren, davon rund 30 mit Sicherheitsbezug. Laut vlts Beitrag zu den Insights-Selektoren nutzen die Sicherheitsselektoren Metadaten von 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

Die Query-Dokumentation führt die Ausgabemodi auf: human, json, mermaid, svg, png und count. Beginnen Sie mit :scripts, denn aus dieser Liste wählt vlt build standardmäßig aus (und überspringt dann bereits gebaute Pakete sowie Pakete mit Malware-Warnungen). Laut vlts Beitrag zum Host-Kontext führt :host(local) eine Abfrage über alle Projekte aus, die im vlt-Dashboard konfiguriert sind.

Dieselben Selektoren funktionieren auch in der 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

Damit der letzte Schritt den Job fehlschlagen lässt, ergänzen Sie --expect-results=0, das in der Query-Dokumentation beschrieben ist. Die Abfrage bleibt überall gleich: Sie ist Ihre Richtlinie, gespeichert als ein einziger Selektor-String.

Fazit: Einen Versuch im Nebenprojekt wert, aber noch nicht der Standard

vlt lohnt schon jetzt einen Versuch in einem Nebenprojekt. Ein Produktionsteam sollte bei seinem bisherigen Paketmanager bleiben, bis die eigene CI, die Authentifizierung gegenüber privaten Registries und die Pakete mit Installationsskripten unter vlt fehlerfrei laufen. Phasenweise Installation und vlt query sind nützlich. Die frische Lockfile-Auflösung und die Wahl der Registry erfordern dagegen eine bewusste Entscheidung. Wenn Ihnen vor allem die Installationsgeschwindigkeit wichtig ist, vergleichen Sie mit dem Rust-Rewrite von pnpm 12 in Ihrem eigenen Repository.

Starten Sie auf einem Branch. Setzen Sie den Registry-Alias npm explizit, führen Sie vlt install, vlt build und vlt query ':scripts' aus und vergleichen Sie die aufgelösten Versionen in vlt-lock.json per Diff mit Ihrem alten Lockfile, bevor irgendetwas in main landet.

FAQs

Welche Node.js-Version benötigt vlt, und wird weiterhin ein node_modules-Ordner angelegt?

Das vlt-Paket benötigt Node.js 22.22 oder neuer. vlt legt weiterhin ein node_modules-Verzeichnis an, verwendet darin aber ein eigenes internes Layout unter node_modules/.vlt/. Das unterscheidet sich vom flachen Baum von npm. Standardmäßig verlinkt vlt unter Linux Dateien per Hardlink aus einem globalen Store und entpackt unter macOS und Windows jedes Paket einzeln; die Einstellung store-linker ändert dieses Verhalten. Pakete werden zur Laufzeit weiterhin normal aufgelöst, sodass Ihr Anwendungscode nicht angepasst werden muss.

Was ersetzt npx und npm run bei der Verwendung von vlt?

vlt exec ersetzt npx. Sie können es auch als vlt x oder über die Kurzform vlx aufrufen. Es führt ein Paket-Binary aus und lädt das Paket herunter, falls es nicht in node_modules liegt – wobei es vorher nachfragt, bevor es etwas Neues abruft. vlxl führt nur bereits installierte Binaries aus. vlt run, abgekürzt vlr, führt Skripte aus der package.json samt ihren pre- und post-Hooks aus. Beide akzeptieren einen --scope-Selektor, um gezielt Workspaces anzusprechen.

Wie migriere ich npm-Overrides zu vlt?

Das Gegenstück zum overrides-Feld von npm heißt bei vlt Graph Modifiers. Sie definieren diese in der vlt.json und schreiben sie als Abfragen in der Dependency Selector Syntax. So können Sie eine Abhängigkeit über Pfad, Workspace oder Semver-Bereich ansprechen, nicht nur über den Paketnamen. Treffen mehrere Modifier auf dieselbe Abhängigkeit zu, entscheidet vlt anhand CSS-ähnlicher Spezifitätsregeln, welcher Vorrang hat.

Wie konfiguriere ich Workspaces in einem vlt-Monorepo?

vlt liest das workspaces-Feld Ihrer Root-package.json unverändert ein, sodass ein bestehendes npm- oder yarn-Monorepo ohne Anpassungen funktioniert. Verwenden Sie das workspaces-Feld der Root-vlt.json, wenn Sie benannte Gruppen möchten oder von pnpm-workspace.yaml migrieren. Enthält die vlt.json ein workspaces-Feld, verwendet vlt ausschließlich dieses und ignoriert das Feld in der package.json; die beiden werden nicht zusammengeführt. In der vlt.json kann der Wert ein Glob-String, ein Array von Globs wie packages/* oder ein Objekt mit benannten Gruppen sein, die jeweils auf Pfade oder Globs verweisen. Ein einfaches Array landet in der Standardgruppe namens packages.