Eine package.json so prüfen, wie npm sie liest: Name, Version, Lizenz, Abhängigkeiten und Syntax
Läuft in Ihrem Browser. Nichts, was Sie eingeben, wird irgendwohin gesendet. Geprüft am 16. Oktober 2026.Ein package.json-Validator prüft die Datei, die npm liest, bevor es ein Paket installiert oder veröffentlicht. Fügen Sie die Datei ein und sehen Sie JSON-Syntaxfehler mit ihrer Zeile, die genauen Warnungen, die npm ausgibt, ob der Name erlaubt ist, ob die Lizenz einer von 734 SPDX-Kennungen entspricht, und Abhängigkeitsversionen, die keine echten Bereiche sind.
Diese Seite wurde maschinell aus dem englischen Original übersetzt. Die Übersetzung wurde noch von keinem Menschen geprüft; maßgeblich ist die englische Fassung. Englisches Original lesen
Fügen Sie die package.json ein, öffnen Sie die Datei oder klicken Sie auf Beispiel ausprobieren.
Beheben Sie zuerst JSON-Syntaxfehler: Zeile und Spalte werden angezeigt, mit der üblichen Ursache.
Lesen Sie, was npm sagt: die Warnungen und Fehler, die npm selbst für diese Datei ausgibt, wortwörtlich.
Arbeiten Sie die weiteren Prüfungen ab, etwa Abhängigkeiten ohne feste Version, und klicken Sie auf Bericht kopieren, um sie weiterzugeben.
npm liest package.json an manchen Stellen streng und an anderen großzügig: Eine falsche Version stoppt alles, eine fehlende Beschreibung bringt nur eine Warnung. Diese Seite prüft die Datei in drei Ebenen und zeigt jede getrennt an.
1. JSON-Syntax. Der erste Fehler wird mit Zeile, Spalte und der üblichen Ursache angezeigt: ein abschließendes Komma, ein Kommentar, einfache Anführungszeichen oder ein Schlüssel ohne Anführungszeichen. Doppelte Schlüssel werden ebenfalls aufgeführt, denn JSON.parse behält stillschweigend nur den letzten, und der erste Wert geht verloren.
2. Was npm sagt. Die Warnungen und Fehler, die npm selbst für diese Datei ausgibt, wortwörtlich, etwa "No repository field." oder "Invalid version". Sie stammen aus einer Neufassung von npms eigenem normalize-package-data, validate-npm-package-name und validate-npm-package-license, und die Tests vergleichen die Antworten mit diesen Paketen an 80 Beispieldateien, 44 Namen und 54 Lizenzangaben.
| npm-Meldung | Was zu tun ist |
|---|---|
| Invalid version: "1.0" | Schreiben Sie drei Zahlen, etwa 1.0.0 |
| No license field. | Fügen Sie "license": "MIT" oder eine andere SPDX-Kennung hinzu |
| license should be a valid SPDX license expression | Verwenden Sie die exakte Kennung, etwa Apache-2.0 |
| scripts['server'] should probably be scripts['start']. | Benennen Sie das Skript in start um |
| name can no longer contain capital letters | Verwenden Sie für ein neues Paket Kleinbuchstaben |
3. Weitere Prüfungen. Abhängigkeiten, die als *, latest oder leere Zeichenkette geschrieben sind; ungültige Versionsbereiche, geprüft mit denselben Regeln wie bei npm; ein Paket, das sowohl in dependencies als auch in devDependencies steht; Git-Abhängigkeiten ohne Tag; lokale Pfade in einem veröffentlichten Paket; ein "type" außer module oder commonjs; engines-Bereiche; und das Platzhalter-Testskript, das npm init hinterlässt.
Eine mit "private": true markierte Datei wird nie veröffentlicht, daher schweigt npm zu ihren Warnungen; die Seite weist darauf hin. Alles läuft in Ihrem Browser; nichts, was Sie einfügen, wird irgendwohin gesendet.
Das Feld license muss eine exakte SPDX-Kennung sein, etwa MIT, ISC oder Apache-2.0, oder eine Kombination wie (MIT OR Apache-2.0). Knappe Abweichungen wie "mit", "Apache 2.0" oder "BSD" scheitern. Für Closed-Source-Code schreiben Sie UNLICENSED oder SEE LICENSE IN LICENSE.txt, um auf Ihre eigene Datei zu verweisen.
Nicht bei einem neuen Paket. Namen müssen kleingeschrieben, höchstens 214 Zeichen lang und URL-sicher sein, dürfen nicht mit einem Punkt oder Unterstrich beginnen und kein Node.js-Kernmodul wie http sein. Manche alten Pakete haben Großbuchstaben, weil die Regeln später kamen, und npm installiert sie weiterhin, lehnt aber ein neues ab.
Die Version muss eine vollständige semantische Version mit drei Zahlen sein, etwa 1.0.0 oder 2.1.0-beta.1. Wer 1.0, latest oder eine leere Zeichenkette schreibt, verhindert, dass npm das Paket überhaupt liest. npm akzeptiert ein vorangestelltes v und entfernt es, daher wird v1.2.3 als 1.2.3 gelesen.
Meistens ja. Beide akzeptieren jede Version, sodass zwei Installationen im Abstand eines Monats unterschiedliche Hauptversionen mit inkompatiblen Änderungen erhalten können. Schreiben Sie einen Caret-Bereich wie ^4.17.21, der Fehlerbehebungen und Funktionen übernimmt, aber vor der nächsten Hauptversion stoppt, und committen Sie die Lock-Datei, damit jede Installation übereinstimmt.
Nein. package.json ist striktes JSON, und JSON kennt keine Kommentare, sodass eine Zeile mit // oder /* npm daran hindert, die Datei zu lesen. Eine übliche Umgehung ist ein Schlüssel namens "//" mit einem Zeichenkettenwert; npm ignoriert Schlüssel, die es nicht kennt. Die Syntaxprüfung hier zeigt auf die Zeile des Kommentars.
npm warnt, wenn package.json kein repository enthält, weil die npm-Website darüber auf den Quellcode verlinkt. Fügen Sie "repository": {"type": "git", "url": "git+https://github.com/user/repo.git"} hinzu. Die Warnung hält nichts auf, und bei einem mit "private": true markierten Paket lässt npm sie ganz weg.
Sätze und Regeln ändern sich; prüfen Sie die Quelle, bevor Sie sich auf eine Zahl verlassen.
Kommen Sie nicht weiter? Fragen Sie zu package.json-Validator und jeder, der es weiß, kann antworten. Kein Konto nötig.