Eine einzige Zeile, dangerouslyAllowAllBuilds: true, erlaubt jeder Abhängigkeit, die Sie jemals installieren, auch transitiven, Code auf Ihrem Laptop und Ihren CI-Runnern während pnpm install auszuführen. Ein Upgrade auf pnpm 11 verwirft die Overrides, die Sie im package.json-Feld "pnpm" gepflegt haben, um verwundbare Versionen zu patchen, mit nur einer Warnung: pnpm 11 liest dieses Feld nicht mehr. Und seit pnpm 10.34.2 und 11.5.3 wird eine ${NPM_TOKEN}-Zeile in der Projekt-.npmrc nicht mehr expandiert, sodass Installationen fehlschlagen und jemand den echten Token direkt in die Datei einträgt. Dieser Skill findet diese und die weiteren unten aufgeführten pnpm-Fehler und zeigt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scan durch auf pnpm-workspace.yaml, jede .npmrc, package.json-Dateien, die zu einem pnpm-Projekt gehören, und pnpm-lock.yaml. Er kennt die Änderungen zwischen den pnpm-Versionen (Scripts standardmäßig blockiert in pnpm 10; eine eintägige minimumReleaseAge, blockExoticSubdeps und allowBuilds in pnpm 11) und nutzt den packageManager-Pin des Projekts, um nur das zu melden, was für die von Ihnen verwendete pnpm-Version gilt. Er überspringt Kommentare, akzeptiert Loopback-Registries, meldet kein Token in einer .npmrc, die von .gitignore abgedeckt wird, und führt niemals pnpm aus oder installiert etwas. Er gibt BLOCK, REVIEW oder NOT FLAGGED zurück, mit Datei, Zeile, Begründung und einem sichereren Ansatz. Secrets werden niemals ausgegeben.

Was geprüft wird

BLOCK (vor dem Deployment beheben)

• P01: dangerouslyAllowAllBuilds: true, oder eine leere neverBuiltDependencies-Liste bei pnpm 10, wodurch jede Abhängigkeit ihre Install-Scripts ausführt
• P02: eine reine http://-Registry, scoped Registry, Publish-Registry, Override, Catalog-Eintrag oder Lockfile-Tarball (localhost ist unbedenklich)
• P03: Registry-Tokens, _auth- oder _password-Werte, Passwörter in URLs, oder npm-, GitHub- und GitLab-Tokens in eingecheckten pnpm-Dateien
• P04: strict-ssl=false oder strictSsl: false

REVIEW (vor dem Release prüfen)

• P11: Build-Freigaben für Git- oder Tarball-Quellen ohne fixierten Commit, eine neverBuiltDependencies-Sperrliste, oder ein Pin auf pnpm 9 oder älter, der jedes Install-Script ausführt
• P12: die Release-Alter-Verzögerung abgeschaltet (minimumReleaseAge: 0, ein Exclude von '*'), oder pnpm 10 ohne minimumReleaseAge (und warum man es auch bei pnpm 11 explizit setzen sollte)
• P13: Overrides oder Catalog-Einträge, die auf Git-Repositories oder URLs verweisen, oder blockExoticSubdeps: false
• P14: shamefully-hoist, ein publicHoistPattern von '*', oder der hoisted Node-Linker (Phantom-Abhängigkeiten)
• P15: Lockfile abgeschaltet, keine pnpm-lock.yaml im Workspace-Root, oder das Lockfile in .gitignore aufgeführt (Beispiel-, Template- und Fixture-Apps ausgenommen)
• P16: Catalog-Versionen, die sich selbst verändern: '*', latest oder ein anderer Dist-Tag, '>=' ohne Obergrenze
• P17: Einstellungen, die pnpm 11 und neuer nicht mehr anwenden: das package.json-Feld "pnpm", pnpm-Einstellungen in .npmrc, sowie onlyBuiltDependencies und die anderen in pnpm 11 entfernten Einstellungen (pnpm 12 schlägt bei ihnen fehl, wenn der Versions-Pin passt)
• P18: ${VAR}-Platzhalter in den auth-, registry-, proxy- oder client-certificate-Zeilen der Projekt-.npmrc (oder Workspace-Registry- und Proxy-URLs), die das aktuelle pnpm nicht mehr expandiert

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelwerk mit der Begründung, dem sichereren Ansatz und der offiziellen Quelle für jede Regel
• Ein riskantes und ein sicheres Beispiel-Monorepo (pnpm-workspace.yaml, .npmrc, package.json-Dateien und ein Lockfile) und der echte Bericht, den der Scanner für das riskante Beispiel erstellt

Grenzen

Er liest nur die Dateien des Projekts: Einstellungen in der benutzerweiten ~/.npmrc, pnpms globale config.yaml und auth.ini, Umgebungsvariablen und Kommandozeilen-Flags sind nicht bekannt. Lockfiles über 1 MB werden übersprungen. Eine einzeln benannte Datei wird ohne das Lockfile und den Versions-Pin ihres Ordners geprüft. .pnpmfile-Hooks, configDependencies, Patches und die Pakete selbst werden nicht untersucht, und Abhängigkeitsversionen werden nicht gegen Schwachstellendatenbanken geprüft. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 20 Dateien: SKILL.md, der Scanner in scripts/ (5 Python-Dateien), references/rules.md (jede Regel mit Begründung und sicherem Ansatz) und examples/ (12 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

So verwenden Sie es: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agents (für Claude Code: ~/.claude/skills/) und bitten Sie Ihren Agenten dann, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.