Скрипты установки и разрешения npm v12

Установка зависимости может запускать код. В npm v12 права такого выполнения описываются отдельно через allowScripts. В этом уроке подготовим узкую политику для вымышленного lab-native и объясним различие обзора, утверждения и фактической установки.

Документация сверена для npm 12.2.0. Команды ниже предназначены для самостоятельной практики в подходящем реальном проекте; мы их не выполняем. У лаборатории нет устанавливаемых реестровых пакетов.

Разрешение привязано к рассмотренному коду

По текущей документации install-скрипты зависимостей без подходящей записи allowScripts по умолчанию пропускаются. В эту область входят preinstall, install, postinstall и prepare для определённых нерегистровых источников. Политика не является общим запретом любого кода проекта. Она задаёт границу конкретного автоматического выполнения при установке.

В script-policy.fixture.json разрешён lab-native@1.2.3, а lab-helper запрещён. Все пакеты вымышлены, решение демонстрационное. Привязка к версии важна: ревью 1.2.3 не означает рассмотрение будущей 1.3.0. Запись только по имени шире и требует отдельного осознанного основания. Нельзя добавлять её случайно ради исчезновения предупреждения.

Команда npm approve-scripts --allow-scripts-pending имеет режим обзора: она показывает пакеты, которые ещё не покрыты политикой, и не меняет package.json. Сначала изучают исходники и назначение, затем отдельно утверждают конкретный пакет. Обычное npm approve-scripts lab-native по умолчанию записывает привязку к установленной версии, но само имя команды не заменяет ревью.

Не используем --all как стандартное решение. Оно утверждает весь набор нерассмотренных install-скриптов одним действием. Для нашей модели нужно понять необходимость ровно одного пакета, поэтому массовое разрешение противоречило бы результату урока. Этот выбор основан на узкой задаче, а не на предположении, что любой lifecycle-скрипт обязательно вреден.

Есть существенное условие pinning. Если у реестровой зависимости отсутствует resolved в lockfile, npm не может привязать доверенную версию тем же способом. Документация описывает предупреждение и более широкое разрешение по имени в таком случае. В реальном процессе нужно остановиться и разобраться с состоянием lockfile, а не молча считать полученное разрешение узким. Наш fixture сохраняет источник, но не является настоящим lockfile.

Что не обеспечивает ignore-scripts

Параметр ignore-scripts отключает автоматические скрипты соответствующей области. Но явная команда npm run продолжает выполнять предназначенный основной скрипт; пре- и пост-обёртки не запускаются в таком режиме. Поэтому нельзя объявить среду безопасной для запуска неизвестного build.mjs только из-за ignore-scripts. Основной код всё равно получит права процесса.

В «Контуре выпуска» build.mjs авторский и доступен целиком. Он не содержит установки, сетевых запросов или публикации. Тем не менее он читает и пишет локальные файлы, поэтому для реального выполнения нужна выбранная рабочая папка. Учебная политика install-скриптов не является песочницей для этого кода. Разделение помогает не приписывать одному флагу защиту всех стадий.

Для каждого разрешения создадим карточку: пакет, версия, источник, просмотренный скрипт, причина необходимости, ресурсы и дата повторного разбора. Состояние pending означает незавершённое решение, denied — намеренный запрет, approved_pinned — ограниченное разрешение. Отказ не следует автоматически переутверждать при новой установке.

Результат — одна демонстрационная привязанная запись, один запрет и отдельный план обзора. Политика не запускалась и не меняла настоящий package.json ProfessorWeb. Следующий урок разберёт обновление дерева до установки, чтобы появление новой версии и нового скрипта не скрывалось за прежним разрешением.

Для команды с несколькими версиями одного пакета особенно важно читать итоговую запись. Утверждение по имени выбирает установленные версии, а сложная политика может выражать намерение автора. Нельзя считать, что повторный вызов всегда безопасно сохраняет первоначальную область. В документации отдельно описаны правила обновления существующей привязки и приоритет явного запрета.

Не добавляйте в архив реальный вывод pending, если он не получен. Наш список называется pending-scripts.fixture.json и содержит fictional:true. Его достаточно для объяснения последовательности решения. Получение реального списка, чтение исходников установленного пакета и последующее разрешение являются будущими самостоятельными операциями в авторизованной среде.

Разбор ожидающего разрешения

В pending-scripts.fixture.json найдите lab-native 1.2.3. Причина pending — отсутствие завершённого решения, а не утверждение о вредоносности. Затем откройте карточку ревью и политику. Разрешение появляется лишь после описанного отдельного решения, поэтому эти документы нельзя объединять в автоматическую команду «разрешить всё, что показано в списке».

Состояние	Действие по смыслу договора
pending	Изучить нужность и код конкретного скрипта, сохранив неизвестное до завершения предметного рассмотрения пакета.
approved_pinned	Разрешение относится к рассмотренной версии и не является обещанием о доброкачественности будущих изменений.
denied	Намеренный запрет сохраняется отдельно и не отменяется только потому, что очередная установка снова упомянула пакет.
explicit run	Основной проектный скрипт требует собственного доверия и не блокируется автоматически политикой lifecycle-установки зависимостей.

В модельном policy JSON записи по имени и по версии имеют разную ширину. Сравните их словами: «данный рассмотренный экземпляр» и «любая подходящая будущая версия имени». Если команда управления политикой меняет область, это должно быть видно в ревью. Правильный синтаксис не заменяет правильное намерение.

Особенно внимательно читайте случай отсутствующего resolved. В документации он имеет собственное поведение привязки, поэтому важно сохранить предупреждение и источник. Не стоит молча добавлять имя без версии, а затем считать задачу узкого разрешения завершённой. Для настоящего проекта потребуется разобраться с деревом отдельной операцией; наша модель не выполняет его обновление.

Вариант для самостоятельного разбора: полезный скрипт создаёт файл, который нужен сборке. Отказ может привести к отсутствующему артефакту. Решение должно либо разрешить конкретный рассмотренный механизм, либо изменить способ получения файла. Оно не должно обходить политику массовым флагом только ради зелёного результата. Такой вариант показывает, что безопасность состоит в понятном выборе полномочий, а не в предположении, что все скрипты одинаковы.

У разрешения полезно сохранить основание повторного просмотра. Новая версия пакета, изменившийся источник и другой способ выполнения являются самостоятельными поводами. Если эти события не записаны, привязка может выглядеть узкой технически, но потерять содержательное объяснение принятого решения.

# Только обзор в собственном реальном проекте; здесь не выполнялось.
npm approve-scripts --allow-scripts-pending
# Отдельное решение после ревью конкретной установленной версии.
npm approve-scripts lab-native

Полный основной артефакт script-policy.fixture.json выбранного состояния:

{
  "fictional": true,
  "not_active_project_policy": true,
  "policy_version": "policy-v1",
  "allowScripts": {
    "lab-native@1.2.3": true,
    "lab-helper": false
  },
  "approval_status": "demonstration_only",
  "execution": "not_run",
  "note": "Конкретная запись иллюстрирует scope; настоящие исходники не просмотрены, пакеты не установлены."
}

Все исходники серии: папка lesson-03 содержит полный самостоятельный снимок, собственный проект и авторские модели. Исполнение примеров, npm, установки, аудит, тесты, CI, настройки и публикация не выполнялись.

Первичные источники: scripts, config.