Package.json-Diff: npm-Manifeste online vergleichen
Fügen Sie das alte package.json links ein, das neue rechts, und sehen Sie genau, welche dependencies, scripts und engines sich geändert haben. Läuft im Browser, nichts wird hochgeladen.
Was dieses package.json-Diff-Tool ist
Ein kostenloses Browser-Tool zum nebeneinander Vergleichen zweier npm package.json-Dateien. Fügen Sie das alte Manifest links ein, das neue rechts, und die Unterschiede werden zeichenweise hervorgehoben. Der Text verlässt nie Ihren Rechner, was zählt, wenn das Manifest zu einem privaten Repository oder einem unveröffentlichten Produkt gehört.
Es ist für den Moment gebaut, in dem ein Renovate- oder Dependabot-PR landet und Sie wissen müssen, was sich jenseits der Versionssprünge wirklich geändert hat. Hat jemand eine Script-Änderung eingeschmuggelt? Ist das engines-Feld von Node 18 auf Node 20 gewandert? Wurde eine peerDependency enger gezogen? Die Diff-Ansicht von GitHub beantwortet einen Teil davon, aber zwei Manifeste in eine saubere Zwei-Panel-Ansicht zu kleben ist schneller, wenn Sie mehrere PRs hintereinander durchgehen oder Branches vergleichen, die noch nicht gepusht sind.
Darunter ist es das gleiche JSON-bewusste Diff, das unsere compare-json-Seite antreibt, mit Rahmen und Text, die auf npm- und yarn-Workflows abgestimmt sind. Beide Manifeste werden als JSON geparst und schön ausgegeben, bevor das Diff läuft, sodass kosmetische Whitespace-Unterschiede die Hervorhebung nicht verschmutzen. Wenn Sie ein rohes Text-Diff für ein Nicht-JSON-Manifestformat brauchen, deckt unser compare-text-Tool das ab, und compare-yaml behandelt pnpm-lock.yaml.
Wie das Diff tatsächlich funktioniert
Jedes Panel wird als JSON geparst. Wenn das Parsen erfolgreich ist, wird das Manifest mit konsistenter zwei-Leerzeichen-Einrückung neu formatiert und die Schlüsselreihenfolge wird beibehalten, wie geschrieben. Wenn das Parsen fehlschlägt (ein verirrtes Komma, eine fehlende Klammer, ein Copy-Paste, das zu wenig Zeichen erwischt hat) fällt das Tool in den Klartextmodus zurück und sagt Ihnen, welche Zeile gebrochen ist. Sobald beide Seiten gültiges JSON sind, läuft das Diff zeichenweise, dann gruppiert ein semantischer Aufräum-Durchgang die Änderungen wieder zu lesbaren Brocken, sodass ein Versionssprung von ^18.2.0 auf ^19.0.0 als eine Bearbeitung gelesen wird, nicht als neun Zeichen-Bearbeitungen.
Einfügungen im rechten Panel werden grün gerendert; Löschungen im linken Panel werden rot gerendert. Die zwei Panels sind beim Scrollen gekoppelt, wenn Sie also tief in devDependencies auf einer Seite eine Änderung finden, springt die andere Seite zum gleichen Schlüssel. Weil das Diff nach dem schönen Ausgeben textuell ist, sieht es strukturelle Änderungen so, wie ein Mensch sie liest: eine entfernte Abhängigkeit verschwindet als Zeile, ein geänderter semver-Bereich hebt sich innerhalb des Werts hervor, ein neues Script rutscht im scripts-Block an die Position, an die Sie es gesetzt haben.
Was das Tool absichtlich nicht tut: Es ist kein Dependency-Resolver. Es sagt Ihnen nicht, welche transitiven Pakete ein Caret-Bereich-Sprung zieht, ob ein Peer erfüllt ist, oder ob die neue Version einen Sicherheitshinweis einführt. Dafür führen Sie lokal npm install gefolgt von npm audit aus, oder verwenden npm mit einem lockfile-bewussten Dienst wie Snyk oder GitHubs Dependabot-Alerts. Diese Seite sagt Ihnen, was der Manifest-Text sagt. Die Auflösungsarbeit gehört zu Ihrem Paketmanager.
Wie man ein package.json in drei Schritten diffed
Zwei Textpanels, ein Diff. Keine CLI-Flags, kein Installationsschritt, kein Patch-Format zum Lesen.
- 1
Altes Manifest links einfügen
Kopieren Sie die vorherige Version von package.json aus Ihrem Editor, aus git show main:package.json, oder von einem Teamkollegen. Fügen Sie ins linke Panel ein. Das Tool wird es als JSON parsen und schön ausgeben; wenn das JSON ungültig ist, zeigt der Editor den Parse-Fehler an, sodass Sie das Snippet vor dem Diff korrigieren können.
- 2
Neues Manifest rechts einfügen
Machen Sie dasselbe mit der aktualisierten Version. Wenn Sie einen Renovate- oder Dependabot-PR prüfen, ist die einfachste Quelle die Rohdatei aus dem PR-Branch. Beide Dateien werden mit konsistenter Einrückung schön ausgegeben, sodass kosmetische Whitespace-Bearbeitungen nicht als falsche Änderungen im Diff auftauchen.
- 3
Hervorgehobene Unterschiede lesen
Löschungen erscheinen als rote Durchstreichungen links; Einfügungen erscheinen als grün rechts. Scannen Sie zuerst die Dependency-Blöcke, prüfen Sie dann den scripts-Abschnitt auf Befehlsbearbeitungen, dann die engines- und peerDependencies-Felder. Versionssprünge innerhalb eines einzelnen Werts heben die geänderten Zeichen hervor, sodass Sie auf einen Blick einen Patch-Sprung von einem Major unterscheiden können.
Wann ein package.json-Diff die richtige Wahl ist
Einen Renovate- oder Dependabot-PR prüfen
Ein Bot öffnet fünfzehn PRs an einem Vormittag. Die meisten sind Routine, aber einer hat eine Script-Änderung eingeschmuggelt, oder eine engere peerDependency, oder einen engines-Sprung, der Ihr CI-Image bricht. Der PR-Titel sagt "chore(deps): bump foo from 4.1.0 to 4.2.1" und Sie vertrauen auf Autopilot. Fügen Sie die Vorher-Nachher-package.json ins Diff ein und Sie können in fünf Sekunden verifizieren, dass sich nichts anderes bewegt hat. Das ist der häufigste einzelne Grund, warum JS-Ingenieure nach einem Manifest-Diff greifen.
Zwei Branches vor dem Mergen vergleichen
Sie und ein Kollege haben beide package.json in separaten Feature-Branches angefasst. Git wird sauber mergen, weil die Bearbeitungen in verschiedenen Blöcken sind, aber ein sauberer Merge bedeutet keinen korrekten. Fügen Sie die Manifeste der zwei Branches ins Diff ein, um ein Script zu entdecken, das ein Branch fallengelassen hat, eine Abhängigkeit, die ein Branch herabgestuft hat, oder einen Konflikt, bei dem beide Branches dasselbe Paket in verschiedenen Versionen hinzugefügt haben. Billiger als es zu entdecken, nachdem CI npm ci gegen das gemergte Ergebnis ausgeführt hat.
Auditieren, was npm install in package-lock.json befördert hat
package.json zu bearbeiten ist die Hälfte der Änderung. Die andere Hälfte ist, was package-lock.json über den aufgelösten Baum aufzeichnet. Nach dem Ausführen von npm install, fügen Sie die alte Lockfile neben die neue ein, um zu sehen, welche transitiven Pakete mitgekommen sind. Überraschungs-Hinzufügungen sind häufig, wenn ein Caret-Bereich einen neuen Minor einer tief verschachtelten Abhängigkeit hereingezogen hat. Für rohe Lockfile-Inspektion behandelt unsere compare-json-Seite die größeren Dateien besser; diese Seite ist am besten für das Manifest selbst.
Ein Downgrade nach einer Regression prüfen
Ein Release geht raus, ein Bug taucht auf, Sie bisecten, und der Verdächtige ist irgendwo im Dependency-Baum. Fügen Sie das package.json des letzten guten Release neben das aktuelle. Streichen Sie unveränderte Blöcke gedanklich raus und konzentrieren Sie sich auf die hervorgehobenen Versionsbereiche. Der Fix ist oft ein Downgrade einer Bibliothek auf die im letzten grünen Build gepinnte Version. Sobald Sie den Verdächtigen gefunden haben, sperren Sie ihn mit einer exakten Version (kein Caret, keine Tilde), bis das Upstream-Problem gelöst ist.
Ihr lokales Manifest mit dem eines Teamkollegen vergleichen
Zwei Ingenieure, ein heikler Merge, zwei verschiedene package.json-Dateien am Ende des Rebase. Die Lockfile ist noch verwirrter. Fügen Sie beide Manifeste nebeneinander ein, um zu sehen, welche Schlüssel sich widersprechen, dann lösen Sie sie bewusst auf, statt das Ergebnis von git merge -X theirs ohne Lesen anzunehmen. Das ist auch das richtige Tool, wenn Sie einen neuen Mitwirkenden einarbeiten, dessen npm install einen anderen Baum als Ihren holt und Sie einen Manifest-Drift vermuten.
Pre-Publish-Review der package.json einer Bibliothek
Bevor Sie npm publish auf einer Bibliothek ausführen, sind die Manifestfelder, die zählen, andere als bei einer App: main, module, types, exports, files, peerDependencies, engines. Diffen Sie das gleich-zu-veröffentlichende Manifest gegen das zuletzt veröffentlichte. Ein fallengelassener peerDependencies-Eintrag, eine geänderte exports-Bedingung, oder ein engerer engines-Bereich kann Konsumenten auf Arten brechen, vor denen npm selbst nicht warnt. Die Node.js packages docs sind die Referenz dafür, was diese Felder bedeuten.
Wissenswerte package.json-Felder
Die Felder, die in echten package.json-Diffs auftauchen und was sie bedeuten. Lohnt sich zu scannen, bevor Sie einen Renovate-PR abnicken oder zwei Branches mergen, die beide das Manifest angefasst haben.
| Topic | What this tool does |
|---|
| dependencies vs devDependencies vs peerDependencies | dependencies werden mit Ihrem Paket ausgeliefert und von jedem installiert, der es konsumiert. devDependencies werden nur installiert, wenn Sie npm install im Projekt-Root ausführen, niemals für Downstream-Konsumenten. peerDependencies sind Pakete, die Ihre Bibliothek erwartet, dass der Host sie bereitstellt (typischerweise React, das Test-Framework, der Bundler) und npm 7+ wird sie automatisch installieren, sofern sie nicht in Konflikt geraten. Ein Paket zwischen diesen Blöcken zu verschieben ändert, wer die Installationskosten zahlt. |
|---|
| Caret- (^) vs Tilde- (~) semver-Bereiche | Caret ^1.2.3 erlaubt jede Version bis aber nicht einschließlich 2.0.0; das ist npms Standard und der lockerste gemeinsame Bereich. Tilde ~1.2.3 erlaubt nur Patches, bis aber nicht einschließlich 1.3.0. 1.2.x ist dasselbe wie Tilde. * bedeutet jede Version (verwenden Sie das nicht in Produktion). latest löst zur Installationszeit auf und produziert nicht-reproduzierbare Builds, also vermeiden Sie es. |
|---|
| Exaktes Pinning (kein Bereichspräfix) | "react": "18.2.0" ohne Caret oder Tilde zu schreiben pinnt auf genau diese Version. Kombiniert mit einer Lockfile gibt Ihnen das die reproduzierbarste Installation um den Preis, Sicherheitspatches niemals automatisch zu erhalten. Manche Teams pinnen alles; andere verlassen sich auf die Caret-plus-Lockfile-Kombination. Es gibt keine universell richtige Antwort, aber der Trade-off ist deterministischere Builds gegen veraltetere Abhängigkeiten. |
|---|
| Determinismus von package-lock.json | package-lock.json zeichnet die exakt aufgelöste Version jedes Pakets im Dependency-Baum auf, einschließlich Transitiver. npm ci installiert aus der Lockfile und weigert sich, sie zu modifizieren; npm install kann sie aktualisieren, wenn ein Bereich eine neuere Version erlaubt. Für CI verwenden Sie immer npm ci. Für Entwickler ist npm install in Ordnung, solange Sie die resultierende Lockfile-Änderung committen. |
|---|
| workspaces-Feld für Monorepos | Das workspaces-Array sagt npm, Schwesterverzeichnisse als verlinkte Pakete in einem Monorepo zu behandeln. npm install im Root installiert alle workspaces und erstellt einen einzelnen gehoisteten node_modules-Baum. Yarn und pnpm unterstützen workspaces mit ihren eigenen Konventionen, und pnpm im Besonderen hoistet weniger aggressiv, was mehr Dependency-Leak-Bugs zur Installationszeit erwischt. |
|---|
| engines-Feld | engines.node deklariert die Node.js-Versionen, die Ihr Paket unterstützt. Standardmäßig warnt npm nur, wenn der Host das verletzt; engine-strict=true in .npmrc macht es zu einem harten Fehler. Das engines-Feld zu bumpen ist eine brechende Änderung für Konsumenten, die auf älterem Node festsitzen, und es ist die Art von Änderung, die sich in einem Renovate-"chore"-PR versteckt. Lesen Sie immer das engines-Diff. |
|---|
| exports-Feld für ES modules | Das exports-Feld kontrolliert, welche Pfade Konsumenten aus Ihrem Paket importieren können und welche Bedingungen (import, require, types, node, browser) zu welchen Dateien aufgelöst werden. Einen Eintrag hinzuzufügen oder zu entfernen ist eine brechende Änderung für Downstream-Code. Die Node.js packages-Dokumentation deckt die Auflösungsregeln im Detail ab; behandeln Sie jedes exports-Diff als major-versionswürdige Bearbeitung, es sei denn, Sie fügen absichtlich einen neuen Eintragspunkt hinzu. |
|---|
| Dateireihenfolge innerhalb von package.json | Es gibt keine erzwungene Reihenfolge für Top-Level-Schlüssel in package.json. Konventionsgemäß starten die meisten Projekte mit name, version, description, dann scripts, dann Abhängigkeiten. Innerhalb von Dependency-Blöcken ist alphabetische Reihenfolge nach Schlüssel der De-facto-Standard und die meisten Paketmanager sortieren den Block beim Speichern. Ein Diff, das umgeordnete aber sonst identische Einträge zeigt, ist meist ein Tooling-Unterschied, keine echte Änderung. |
|---|
Package.json-Diff: häufig gestellte Fragen
Wie unterscheidet sich das von npm diff oder npm-check-updates?
npm diff ist ein eingebauter npm-Befehl, der zwei veröffentlichte Versionen eines Pakets im Registry vergleicht, einschließlich ihrer Tarballs und Quellen. npm-check-updates (ncu) meldet, welche Abhängigkeiten in Ihrem Manifest neuere Versionen verfügbar haben. Keiner zeigt Ihnen den Unterschied zwischen zwei beliebigen package.json-Dateien, die Sie auf der Festplatte oder in zwei Branches haben. Dieses Tool macht das. Verwenden Sie ncu, um herauszufinden, dass Sie upgraden sollten, npm diff, um Registry-seitige Änderungen zwischen Releases zu sehen, und diese Seite, um Ihr eigenes Vorher-Nachher-Manifest in einer Side-by-Side-Ansicht zu lesen.
Auditiert es Sicherheit oder prüft auf bekannte Schwachstellen?
Nein. Diese Seite diffed nur den Text. Sie fragt nicht das npm-Registry, die GitHub Advisory Database oder irgendeinen Schwachstellendienst ab. Für Sicherheitsauditing führen Sie npm audit gegen einen installierten Baum aus, verwenden npm audit signatures, um die Paketherkunft zu verifizieren, oder verlassen sich auf Snyk-, Socket- oder Dependabot-Alerts. Dieses Tool ist die richtige Wahl, wenn Sie wissen wollen, was sich im Manifest geändert hat. Es ist die falsche Wahl, wenn Sie wissen wollen, ob die Änderung sicher zum Ausliefern ist.
Erkennt es transitive Abhängigkeitsänderungen?
Nicht aus dem Manifest allein. package.json listet nur direkte Abhängigkeiten und ihre angeforderten Bereiche auf. Der vollständige aufgelöste Baum, einschließlich Transitiver, lebt in package-lock.json (oder yarn.lock oder pnpm-lock.yaml). Um aufgelöste Bäume zu vergleichen, fügen Sie beide Lockfiles in ein Diff ein. Weil Lockfiles groß sind, behandelt sie unsere compare-json-Seite besser als diese hier. Für pnpm-lock.yaml speziell verwenden Sie compare-yaml. Diese Seite ist auf das Manifest optimiert.
Wie vergleiche ich zwei package-lock.json-Dateien?
Fügen Sie beide Lockfiles in die Panels ein, genauso wie Sie es mit einem Manifest tun würden. Das Tool wird sie als JSON parsen, schön ausgeben und diffen. Beachten Sie, dass Lockfiles zu Tausenden von Zeilen anwachsen können, das hervorgehobene Diff also lang sein kann. Konzentrieren Sie sich zuerst auf die Top-Level-packages-Einträge, dann auf die version-Felder. Für Dateien größer als etwa fünftausend Zeilen passt unsere compare-json-Seite besser, weil sie eingerichtet ist, große JSON-Payloads mit derselben Engine zu behandeln.
Was ist der Unterschied zwischen Caret- (^) und Tilde- (~) Bereichen?
Beide sind semver-Bereiche, die Updates erlauben, ohne das Manifest manuell zu bearbeiten. Das Caret ^1.2.3 erlaubt jede Version, die die linkste nicht-null-Ziffer nicht ändert, also 1.2.3 bis 1.999.999 werden akzeptiert, aber 2.0.0 nicht. Die Tilde ~1.2.3 ist strenger: erlaubt nur Patch-Updates, also 1.2.3 bis 1.2.999 werden akzeptiert, aber 1.3.0 nicht. Caret ist der npm-Standard und der lockerere Bereich; Tilde ist das, wonach Sie greifen, wenn eine Bibliothek eine Geschichte von brechenden Minor-Releases hat.
Gibt es Größenbeschränkungen für große Lockfiles?
Praktisch ja. Das Diff läuft in Ihrem Browser, sehr große Eingaben (eine 20.000-Zeilen-Lockfile aus einem Monorepo zum Beispiel) können also je nach Speicher die Seite verlangsamen oder den Tab zum Stillstand bringen. Für typische App-Manifeste und Lockfiles bis zu ein paar Tausend Zeilen pro Seite ist das Diff praktisch sofort fertig. Für größere Dateien ist unsere compare-json-Seite der bessere Einstiegspunkt. Wenn Sie regelmäßig riesige Lockfiles vergleichen, erwägen Sie, git diff package-lock.json lokal auszuführen und in einen Pager zu pipen; dieser Workflow skaliert weiter als jedes Browser-Tool.
Datenschutz und wie das funktioniert
Ihre Manifeste verlassen nie Ihren Browser. Das Diff, das JSON-Parsen, das Hervorheben und das Rendern laufen alle auf Ihrem Rechner. Wir laden den Text nicht hoch, loggen ihn nicht, und geben ihn an keinen Drittanbieterdienst weiter. Das zählt speziell für proprietären Code: das package.json einer unveröffentlichten Bibliothek oder die Lockfile eines privaten Repositorys in einen Cloud-Dienst zu kleben kann selbst die Datenverarbeitungsrichtlinie Ihres Arbeitgebers verletzen, besonders wenn das Manifest interne scoped Pakete, private Registry-Hosts oder in Entwicklung befindliche Produktnamen nennt. Die Behauptung zu verifizieren ist direkt. Öffnen Sie die DevTools Ihres Browsers, wechseln Sie zum Network-Tab, fügen Sie beide Manifeste ein und beobachten Sie. Es gibt keine ausgehenden Anfragen, wenn Sie vergleichen. Dasselbe Datenschutzmodell gilt in unseren anderen Tools, einschließlich compare-json, compare-yaml für pnpm-lock.yaml, und git-diff-online für allgemeine Code-Reviews. Für die zugrundeliegende Spezifikation siehe Yarns Konfigurationsreferenz und die npm package.json-Dokumentation.