Текст и данные · Инструкция
pnpm approve-builds разрешить build scripts зависимостей
`pnpm approve-builds` используется для явного разрешения build-скриптов зависимостей, которые pnpm не должен запускать без доверия. Команда появилась в pnpm 10.1; в актуальной документации решение записывается в `pnpm-workspace.yaml`, поэтому перед подтверждением важно понимать, какой пакет и какой install-скрипт вы разрешаете.
Короткий ответ
`pnpm approve-builds` позволяет явно разрешить выбранным зависимостям install/build scripts и сохранить решение в конфигурации workspace.
Как команда влияет на pnpm-workspace.yaml и install scripts
Build scripts выполняют код во время установки, поэтому одобрение является решением о доверии к цепочке поставки. Текущая документация pnpm сохраняет одобрения/запреты через `allowBuilds` в `pnpm-workspace.yaml`. До одобрения стоит проверить имя, версию, назначение скрипта и официальный источник пакета; массовое разрешение всех кандидатов обесценивает защитный механизм.
Совет: Перед подтверждением откройте пакет и поймите назначение его lifecycle-скрипта — имя зависимости само по себе недостаточно.
Порядок действий для postinstall
- Шаг 1: Определите пакет, которому pnpm не дал выполнить build/install script, и зафиксируйте точную версию.
- Шаг 2: Просмотрите `scripts` пакета и выясните, зачем проекту нужен этот этап — например, генерация нативного артефакта.
- Шаг 3: Запустите `pnpm approve-builds` и разрешите только проверенные пакеты.
- Шаг 4: Просмотрите diff `pnpm-workspace.yaml`, затем повторите чистую установку и убедитесь, что неожиданные скрипты всё ещё блокируются.
Что должно попасть в diff после approve-builds
- Используется pnpm версии, где `approve-builds` поддерживается.
- Для каждого кандидата понятно, зачем ему нужен install/build script.
- В diff `pnpm-workspace.yaml` попали только осознанно одобренные или запрещённые пакеты.
- После чистой установки нет неожиданных новых build-скриптов.
- Изменение конфигурации закоммичено и проходит code review как security-sensitive файл.
Что проверять перед одобрением build-скрипта
Сначала посмотрите имя, версию и происхождение зависимости, а затем выясните, зачем ей нужен lifecycle/build script. Интерактивный список удобен для ревью нескольких пакетов; имена также можно передать команде явно. После выбора откройте diff `pnpm-workspace.yaml`: разрешение должно относиться только к тем зависимостям, которые вы проверили. Повторная установка должна проходить без неожиданного появления новых кандидатов. Если пакет изменился существенно, не считайте старое решение автоматическим подтверждением новой цепочки поставки. Если после обновления pnpm список кандидатов изменился, пересмотрите новое решение отдельно: разрешение должно относиться к фактически установленной версии зависимости.
Предупреждение: Не одобряйте весь список ради успешной установки: это убирает защитный смысл механизма.
Почему массовое одобрение опасно
Не используйте массовое одобрение как способ убрать предупреждение: install scripts исполняют сторонний код в контексте машины разработчика или CI.
Как проверить, что build-скрипты разрешены выборочно
Одобрение завершено, когда чистая установка запускает только те build-скрипты, которые команда действительно проверила, а решение видно в репозитории. Не превращайте `approve-builds` в механическое «разрешить всё»: смысл функции именно в том, чтобы lifecycle-код зависимости не получил доверие без отдельного решения.
Важно: После выбора обязательно смотрите diff workspace-конфигурации и повторяйте чистую установку.
Что учитывать
Не используйте массовое одобрение как способ убрать предупреждение: install scripts исполняют сторонний код в контексте машины разработчика или CI.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. pnpm approve-builds). Пример и формулировки — редакция N1RO на 2026-09-23.