package.json-Inspektor für Abhängigkeiten und Skripte

Fügen Sie package.json ein, um Abhängigkeitsbereiche, Skripte, Engines und packageManager aufzulisten und zu sehen, welche Versionen unbeschränkt sind oder außerhalb der Registry liegen. Das Werkzeug liest nur das Manifest: Es installiert keine Pakete, führt keine Skripte aus, löst keine Versionen auf und fragt keine Registry ab.

Läuft lokal in deinem Browser

So prüfen Sie ein package.json-Manifest

Fügen Sie ein package.json-Manifest ein und klicken Sie auf Lokal analysieren. Der Text wird mit dem JSON-Parser des Browsers gelesen: Es wird nichts installiert, kein Skript ausgeführt, keine Registry abgefragt, und das Manifest verlässt die Seite nicht.

Der Paketbericht zeigt eine Zusammenfassung aus name, version, packageManager, engines, dependencyCounts und scripts, drei Kacheln für Abhängigkeiten, Skripte und Paketmanager sowie eine Liste, die jede beanstandete Abhängigkeit mit der Versionsangabe genau so nennt, wie sie im Manifest steht.

Fügen Sie das Manifest in das Feld package.json ein oder klicken Sie auf Beispiel laden: ein Manifest mit zod und vite, je einem test- und build-Skript, engines.node >=20, packageManager pnpm@9 und ohne license-Feld.
Klicken Sie auf Lokal analysieren. Beispiel laden analysiert das Beispiel sofort.
Lesen Sie die drei Kacheln: wie viele Abhängigkeiten die vier Bereiche deklarieren, wie viele Skripte es gibt und ob packageManager gesetzt ist.
Gehen Sie die Liste durch. Jeder Eintrag nennt die Abhängigkeit und die Versionsangabe unverändert, ^3.23.0 erscheint also genau so.
Scrollen Sie zu Abhängigkeiten und Skripte: eine Zeile je Abhängigkeit (Bereich, Name, Version) und eine je Skript. Kopieren legt die Zusammenfassung als JSON in die Zwischenablage.

Was der Bericht zählt und was er beanstandet

Was aus dem Manifest gelesen wird

Gelesen werden die vier Abhängigkeitsbereiche - dependencies, devDependencies, peerDependencies und optionalDependencies - in dieser Reihenfolge sowie scripts. Ein Paket, das in zwei Bereichen steht, erscheint zweimal, einmal je Bereich.

Die Zusammenfassung wiederholt die Anzahl je Bereich und die Feldnamen des Manifests selbst; dadurch lässt sie sich mit der eingefügten Datei vergleichen. Alles wird so ausgegeben, wie es deklariert ist: Bereiche werden nicht erweitert, Versionen nicht aufgelöst und keine Felder umgeschrieben.

Was beanstandet wird

„*“ und „latest“ gelten als unbeschränkt; Verweise außerhalb der Registry oder in einen Workspace (github:, https:, git+, file:, workspace:, link:, portal:) werden zur Prüfung gemeldet. Ebenso gemeldet werden ein fehlender engines.node-Bereich, eine fehlende Lizenz und ein Bereich, der kein Objekt ist; der letzte wird zusätzlich übersprungen.

Caret-, Tilde- und Vergleichsbereiche wie ^1.2.3, ~1.2.0, >=1 <2 oder 1.x werden nicht beanstandet - sie sind durch ihre eigene Syntax beschränkt - und ein npm:-Alias zählt als Registry-Verweis. Es wird nichts mit der zuletzt veröffentlichten Version verglichen.

Grenzen

Der Inspektor liest nur den Text des Manifests. Er installiert keine Pakete, führt keine Skripte aus, löst keine Versionen auf, liest keine Lockfile (dafür gibt es den Lockfile-Analysator) und sucht nicht nach Schwachstellen.

Er prüft das Manifest auch nicht gegen das npm-Schema: Felder wie overrides, resolutions oder workspaces werden nicht untersucht, und das JSON muss strikt sein - Kommentare und abschließende Kommas werden mit der Parser-Meldung abgelehnt.