Was steckt wirklich in deiner package.json? Pruef vor dem Shippen
Deine `package.json` landet gleich in npm. Oder in CI. Oder in einem Monorepo, das seit zwei Jahren keiner aufgeraeumt hat. Frage: ist die Datei eigentlich okay? Ist der Name gueltig, die Version sauberes SemVer, hast du dasselbe Package in `dependencies` UND `devDependencies`, wird `"react": "*"` beim naechsten npm install knallen.
Paste die ganze Datei in die Textarea. Der Validator macht vier Dinge:
- prueft, ob es ueberhaupt gueltiges JSON ist (haeufigster Bug: Trailing Comma);
- validiert das npm-Schema: Name matcht Registry-Regeln, Version ist SemVer, Root ist Objekt;
- zeichnet einen Graph deiner Scripts: welches Script ruft welches (z.B. `build` ruft `clean` und `compile`), du siehst sofort, was bei `npm run release` passiert;
- prueft Dependencies: Duplikate zwischen deps und devDeps, Wildcards (`"*"`, `"latest"`), gemischte Styles (`^` vs. `~` vs. exact), fehlende peers.
Alles lokal im Browser. Nichts verlaesst die Seite, du kannst sicher die Firma-`package.json` pasten, niemand sieht Dependency-Namen, Private-Registry-Pfade oder Script-Namen.
So nutzt du das Tool
- Ganze `package.json` pasten in die Textarea oben. Zum Anschauen klick Beispiel laden, der Validator zeigt ein Sample mit absichtlichem Problem.
- Die "Gueltigkeit"-Karte zeigt das Ergebnis sofort gruen oder rot. Gruen = JSON parst und npm-Schema okay. Rot = klick die Fehlerliste fuer Details.
- Die "Metadaten"-Karte zeigt Name, Version, Modul-Typ (ESM oder CommonJS), Lizenz, Repo lesbar.
- Die "Scripts"-Karte zeichnet den Graph: welches Script ruft welches. Du siehst `build` -> `clean` + `compile` -> `tsc`. Goldwert bei einem geerbten Projekt mit 30 Scripts.
- Die "Dependencies"-Karte zaehlt Packages in vier Sections (deps/devDeps/peerDeps/optional) und listet erkannte Probleme: Duplikate, Wildcards, fehlende peers, gemischte Version-Styles.
- Die "Pflichtfelder"-Karte ist eine gruene oder gelbe Checklist: name, version, description, license, scripts, repository. Du weisst sofort, was fehlt, bevor das Package zu npm kann.
- Klick Format, wenn du eine einzeilige `package.json` gepastet hast und sauberes Output zum Zuruecknehmen brauchst.
Wann das nuetzlich ist
Fuenf Situationen, in denen der Validator eine Stunde CI-Debugging spart:
- Vor dem ersten `npm publish`. Ein Package geht zum ersten Mal zu npm. Der Validator prueft, ob der Name gueltig ist (falsche Zeichen = Registry lehnt ab), ob die Version SemVer ist, ob du eine Lizenz hast. Ohne das merkst du es erst beim Fehlschlag.
- Code-Review auf einem Monorepo-PR. Jemand hat ein Package hinzugefuegt. Du pastest die `package.json` in den Validator und siehst sofort **`"react": "*"` in deps**. Du kommentierst den PR, bevor was mergt, das beim naechsten Update bricht.
- Audit eines zu erbenden Projekts. Du uebernimmst ein Legacy-Projekt mit 47 Scripts, die sich gegenseitig rufen. Der Validator zeichnet den Graph, du siehst `release` ruft `build`, das ruft `compile`, das ruft `tsc`. Eine Karte statt 47 Zeilen lesen.
- Rausfinden, warum CI bei `npm ci` fehlschlaegt. Der CI-Build geht nicht. Du pastest die `package.json` und siehst: `package-x` ist in deps UND devDeps, das Lock-File ist verwirrt, `npm ci` waehlt verschiedene Versionen. Der Validator zeigt das als rotes Issue.
- Migration von npm zu pnpm oder yarn. Vor der Migration pastest du beide `package.json`-Dateien (alt und neu) und pruefst, ob Peer-Dependencies konsistent sind, ob Wildcards weg sind (pnpm ist strenger), und ob Scripts einen sinnvollen Graph bilden.
Fragen und Antworten
Nein. Alle Validierung laeuft im Browser. Die Datei verlaesst den Rechner nicht, es gibt keine API. Du kannst sicher eine Firma-`package.json` mit privaten Package-Namen, internen Registry-Pfaden oder Script-Namen wie `deploy-staging` pasten. Der Validator funktioniert 100% offline nach dem ersten Laden.