Одна строка, dangerouslyAllowAllBuilds: true, позволяет любой зависимости, которую вы когда-либо установите, включая транзитивные, запускать код на вашем ноутбуке и ваших CI-раннерах во время pnpm install. Обновление до pnpm 11 отбрасывает overrides, которые вы хранили в поле "pnpm" файла package.json для исправления уязвимых версий, выдавая лишь предупреждение: pnpm 11 больше не читает это поле. А начиная с pnpm 10.34.2 и 11.5.3 строка ${NPM_TOKEN} в проектном .npmrc больше не раскрывается, из-за чего установки завершаются ошибкой, и кто-то вставляет в файл настоящий токен. Этот скилл находит эти и другие ошибки pnpm, перечисленные ниже, и объясняет, как исправить каждую из них.

Ваш агент запускает сканер по pnpm-workspace.yaml, каждому .npmrc, файлам package.json, принадлежащим проекту pnpm, и pnpm-lock.yaml. Он знает, что изменилось между версиями pnpm (скрипты блокируются по умолчанию в pnpm 10; однодневный minimumReleaseAge, blockExoticSubdeps и allowBuilds в pnpm 11) и использует закреплённую в проекте версию packageManager, чтобы сообщать только о том, что применимо к используемой вами версии pnpm. Он пропускает комментарии, принимает loopback-реестры, не сообщает о токене в .npmrc, который покрыт .gitignore, и никогда не запускает pnpm и ничего не устанавливает. Он возвращает BLOCK, REVIEW или NOT FLAGGED с указанием файла, строки, причины и более безопасного подхода. Секреты никогда не выводятся.

Что проверяется

BLOCK (исправьте перед релизом)

• P01: dangerouslyAllowAllBuilds: true, или пустой список neverBuiltDependencies в pnpm 10, из-за чего каждая зависимость запускает свои install-скрипты
• P02: обычный реестр http://, scoped-реестр, publish-реестр, override, запись catalog или tarball в lock-файле (localhost допустим)
• P03: токены реестра, значения _auth или _password, пароли в URL, или токены npm, GitHub и GitLab в закоммиченных файлах pnpm
• P04: strict-ssl=false или strictSsl: false

REVIEW (проверьте перед релизом)

• P11: одобрения сборки для источников git или tarball без закреплённого коммита, deny-лист neverBuiltDependencies, или закрепление на pnpm 9 или более старой версии, при которой запускается каждый install-скрипт
• P12: отключённая задержка по возрасту релиза (minimumReleaseAge: 0, исключение '*'), или pnpm 10 без minimumReleaseAge (и почему стоит задавать его явно также в pnpm 11)
• P13: overrides или записи catalog, указывающие на git-репозитории или URL, либо blockExoticSubdeps: false
• P14: shamefully-hoist, publicHoistPattern со значением '*', или hoisted node linker (фантомные зависимости)
• P15: отключённый lockfile, отсутствие pnpm-lock.yaml в корне рабочего пространства, или lockfile, указанный в .gitignore (примерные, шаблонные приложения и fixture-приложения не учитываются)
• P16: версии catalog, которые меняются сами по себе: '*', latest или другой dist-tag, '>=' без верхней границы
• P17: настройки, которые pnpm 11 и более новые версии не применяют: поле "pnpm" в package.json, настройки pnpm в .npmrc, а также onlyBuiltDependencies и другие настройки, удалённые в pnpm 11 (pnpm 12 завершается с ошибкой на них, если версия закреплена соответствующим образом)
• P18: заглушки ${VAR} в строках auth, registry, proxy или client-certificate проектного .npmrc (или в URL registry и proxy рабочего пространства), которые текущий pnpm больше не раскрывает

Что входит в комплект

• Сканер (Python 3.9+, только стандартная библиотека)
• Руководство по правилам с указанием причины, более безопасного подхода и официального источника для каждого правила
• Рискованный и безопасный примеры монорепозитория (pnpm-workspace.yaml, .npmrc, файлы package.json и lock-файл) и реальный отчёт, который сканер выдаёт для рискованного примера

Ограничения

Он читает только файлы проекта: настройки в пользовательском ~/.npmrc, глобальные config.yaml и auth.ini pnpm, переменные среды и флаги командной строки ему не известны. Lock-файлы размером больше 1 МБ пропускаются. Файл, указанный отдельно, проверяется без lock-файла и закрепления версии его папки. Хуки .pnpmfile, configDependencies, патчи и сами пакеты не проверяются, а версии зависимостей не сравниваются с базами данных уязвимостей. NOT FLAGGED не является гарантией.

Содержимое

Один ZIP-файл с 20 файлами: SKILL.md, сканер в scripts/ (5 файлов Python), references/rules.md (каждое правило с причиной и более безопасным подходом) и examples/ (12 файлов примеров плюс report.md, реальный вывод сканера на рискованном примере).

Как использовать: Это скилл для агента: папка с файлом SKILL.md и скриптами Python, которые может запускать ИИ-агент для написания кода, такой как Claude Code, Cursor или Codex CLI. Распакуйте его в папку скиллов вашего агента (для Claude Code: ~/.claude/skills/), затем попросите агента проверить ваш проект. Скрипты также работают самостоятельно на Python 3.9 или новее, без необходимости что-либо устанавливать. Они только читают ваши файлы: без доступа к сети, и ничего никуда не отправляется.