Layer 8Ehrlicher Tech-Support
SoftwareSchweregrad: Lästig

npm update bringt Version 1.9 nie auf 2.0

npm update bringt Version 1.x nie auf 2.0: Es respektiert die Bereiche in package.json und schreibt sie standardmäßig nicht um.

Aufwand:
ca. 10 Min.
Voraussetzung:
npm CLI, package.json des Projekts, npm-Dokumentation zu npm update und npm outdated
Gilt für:
npm CLI v10 (Dokumentation in der am 2026-10-15 abrufbaren Fassung), Andere npm-Hauptversionen sind hier nicht geprüft

Das Symptom

Der Entwickler führt npm update aus, um alles auf den neuesten Stand zu bringen, und sieht danach in npm outdated immer noch ein Paket auf 1.9.4, obwohl 2.3.0 als latest veröffentlicht ist. Er wiederholt den Befehl, löscht node_modules, probiert npm update paketname, nichts passiert. Verdacht: npm-Cache, Registry-Spiegel, Proxy. Tatsächlich hat npm exakt das getan, was in der package.json steht, und dort steht ^1.9.4, also alles unter 2.0.

Die „Layer 8“-Wahrheit

Die npm-Dokumentation zu npm update sagt es im ersten Satz: „This command will update all the packages listed to the latest version (specified by the tag config), respecting the semver constraints of both your package and its dependencies (if they also require the same package).“ Der Befehl aktualisiert also, aber innerhalb der Grenzen, die das Projekt selbst gezogen hat. Für ^1.9.4 heißt das: alles bis unter 2.0.0, nie 2.x.

Das Beispiel in der Dokumentation führt es mit einer Tilde-Abhängigkeit vor: „Even though the latest tag points to 1.2.2, this version does not satisfy ~1.1.1, which is equivalent to >=1.1.1 <1.2.0. So the highest-sorting version that satisfies ~1.1.1 is used, which is 1.1.2.“ Der Tag latest ist eine Information, kein Befehl; was installiert wird, bestimmt der Bereich.

Außerdem ändert npm update die Bereichsangaben in der package.json standardmäßig nicht: „Note that by default npm update will not update the semver values of direct dependencies in your project package.json.“ Dafür braucht es den Schalter –save. Ein Sprung auf eine neue Hauptversion ist dagegen eine bewusste Entscheidung mit möglichen Brüchen und wird mit npm install paket@latest oder paket@2 gemacht, was den Bereich in der package.json neu setzt.

npm outdated zeigt die drei Spalten Current, Wanted und Latest genau deshalb getrennt: Wanted ist, was der Bereich erlaubt, Latest, was es gibt. Wer die beiden Spalten als Widerspruch liest, sucht den Fehler im Werkzeug. Wer sie als zwei verschiedene Fragen liest, sieht, dass npm beide richtig beantwortet hat, und dass die dritte Frage, ob das Projekt die neue Hauptversion verträgt, nicht npm beantworten kann, sondern nur ein Blick ins Changelog und ein Testlauf.

Der Reflex, bei einer unerwarteten Versionsnummer den Cache zu leeren oder die Registry zu verdächtigen, kommt daher, dass npm selten erklärt, warum es etwas nicht tut. Es tut es einfach nicht. Die Erklärung steht in der package.json, die man selbst geschrieben oder von einem Generator übernommen hat, und sie lautet in einem Zeichen: das Dach vor der Version. Wer es liest, weiß, was npm update darf, und wer es ändert, weiß, dass er es war.

Die echte, verifizierte Lösung

1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:

  1. 1.

    npm outdated lesen, mit beiden Spalten

    npm outdated ausführen und je Paket Current, Wanted und Latest vergleichen. Current gleich Wanted und Latest höher heißt: Der Bereich ist ausgeschöpft, die nächste Version liegt außerhalb. Das ist der Normalfall bei einem Sprung über die Hauptversion und kein Zeichen für einen defekten Cache oder einen Registry-Spiegel.

    npm outdated
  2. 2.

    Für den Sprung auf die Hauptversion die Version benennen

    npm install mit expliziter Version oder mit @latest ausführen. Dadurch wird die Bereichsangabe in der package.json neu gesetzt, und die package-lock.json folgt. Danach die Anwendung testen, denn genau für diesen Schritt gibt es die Hauptversionsgrenze: Die neue Version darf sich anders verhalten.

    npm install paketname@latest
npm install paketname@2
  3. 3.

    npm update --save verwenden, wenn die Bereiche mitziehen sollen

    Innerhalb des erlaubten Bereichs aktualisiert npm update nur die installierte Version. Sollen auch die Angaben in der package.json auf die neu installierte Version angehoben werden, ist --save nötig. Ohne den Schalter bleibt die package.json so, wie sie war, und ein frischer Klon des Projekts installiert wieder, was der alte Bereich erlaubt.

    npm update --save
  4. 4.

    Das Beispiel der Dokumentation nachvollziehen

    Die npm-Dokumentation rechnet es mit einer Tilde-Abhängigkeit vor: „Even though the latest tag points to 1.2.2, this version does not satisfy ~1.1.1, which is equivalent to >=1.1.1 <1.2.0. So the highest-sorting version that satisfies ~1.1.1 is used, which is 1.1.2.“ Dasselbe Prinzip gilt für ^: Der Bereich entscheidet, nicht der Tag. Wer das einmal mit einem eigenen Paket durchspielt, sucht beim nächsten Mal nicht im Cache.

Häufige Fragen (FAQ)

?npm update läuft fehlerfrei, aber das Paket bleibt auf 1.9.4. Warum?

Weil npm genau das tut, was in der package.json steht. Die Dokumentation beschreibt den Befehl so: „This command will update all the packages listed to the latest version (specified by the tag config), respecting the semver constraints of both your package and its dependencies (if they also require the same package).“ Steht dort ^1.9.4, erlaubt der Bereich alles unter 2.0.0, und 2.3.0 liegt außerhalb. npm hat nichts übersehen; es hat die Grenze eingehalten, die das Projekt selbst gesetzt hat.

?Wo zeigt mir npm, dass eine neuere Hauptversion existiert?

In npm outdated, und zwar absichtlich in zwei getrennten Spalten: Wanted ist die höchste Version, die der Bereich in der package.json erlaubt, Latest die Version, auf die der Tag latest in der Registry zeigt. Steht in Wanted 1.9.4 und in Latest 2.3.0, ist das keine Störung, sondern die Auskunft, dass ein Sprung über die Hauptversion ansteht, den npm update nicht von sich aus macht.

?Schreibt npm update die package.json um?

Standardmäßig nicht. Die Dokumentation hält fest: „Note that by default npm update will not update the semver values of direct dependencies in your project package.json.“ Die installierte Version in node_modules und in der package-lock.json ändert sich innerhalb des Bereichs, die Bereichsangabe selbst bleibt stehen. Wer sie mitziehen will, ruft npm update mit --save auf; wer die Hauptversion wechseln will, braucht etwas anderes.

?Wie komme ich dann auf 2.x?

Mit einer bewussten Installation der neuen Version: npm install paket@latest oder npm install paket@2. Das setzt den Bereich in der package.json neu, zum Beispiel auf ^2.3.0, und ab dann hält npm update diesen Bereich ein. Vorher das Changelog des Pakets lesen: Der Bereich mit ^ hält die Hauptversion aus gutem Grund fest, denn eine neue Hauptversion darf nach der Semver-Konvention Änderungen enthalten, die bestehenden Code brechen.

Belege

Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.

  1. [1]
    npm Docs, CLI v10 – npm-update: Abschnitt Description („respecting the semver constraints of both your package and its dependencies“; „by default npm update will not update the semver values of direct dependencies in your project package.json“) und Example „Tilde Dependencies“

    docs.npmjs.com · abgerufen am

  2. [2]
    npm Docs, CLI v10 – npm-outdated (Spalten Current, Wanted und Latest)

    docs.npmjs.com · abgerufen am

Zuletzt geprüft am . Dokumentation altert – ein Datum daneben ist der einzige ehrliche Umgang damit.

Auch zu finden unter

Verwandte Fehler

SWLästig

npm meldet Schwachstellen (vulnerabilities)

npm warnt nach der Installation vor Sicherheitslücken? Nicht jede ist gefährlich — und ein blindes npm audit fix kann mehr kaputt machen, als es behebt.