Релиз npm 11.17.0 усиливает контроль над install-скриптами и подготовку к npm v12

npm 11.17.0 вышел 11 июня 2026 года и продолжает линию изменений, связанных с безопасностью установки зависимостей. Релиз дорабатывает allowScripts, команды approve-scripts и deny-scripts, а также поведение npm при работе с удалёнными tarball-пакетами, локальными ссылками и lifecycle-скриптами публикации.

npm 11.17.0 развивает защиту от нежелательного выполнения скриптов

Команда npm выпустила npm CLI 11.17.0 11 июня 2026 года. Это обновление нельзя назвать крупным по количеству пользовательских функций, но оно важно для разработчиков, которые уже готовят проекты к npm v12 и более строгим правилам установки зависимостей.

Главная тема релиза — контроль над скриптами, которые запускаются во время установки пакетов. В экосистеме JavaScript такие скрипты давно используются для сборки нативных модулей, подготовки файлов и настройки пакета после загрузки. Та же возможность создаёт риск: зависимость может выполнить код на машине разработчика или в CI/CD ещё до того, как команда внимательно изучит содержимое пакета.

В npm 11.17.0 эта область получила несколько точечных улучшений. Релиз исправляет работу approve-scripts и deny-scripts, улучшает JSON-вывод этих команд, учитывает allowScripts в большем количестве операций и делает предупреждения понятнее для глобальных установок.

allowScripts становится центральным механизмом доверия к зависимостям

Параметр allowScripts нужен для явного разрешения install-скриптов у конкретных пакетов. Вместо автоматического выполнения всех preinstall, install и postinstall проект может зафиксировать список зависимостей, которым разрешено запускать такие сценарии.

В npm 11.17.0 появился ряд доработок вокруг этого механизма:

ИзменениеПрактический смысл
approve-scripts и deny-scripts стали корректнее обрабатывать аргументы с точками и версиямиКоманды лучше работают с реальными именами пакетов и версиями
approve-scripts --json и deny-scripts --json теперь отдают валидный JSONАвтоматизация и CI-инструменты могут безопаснее разбирать результат
approve-scripts показывает ожидающие проверки скрипты даже при включённом ignore-scriptsКоманда видит, какие пакеты требуют решения, без запуска самих скриптов
allowScripts учитывается в prune, dedupe, uninstall, audit и linkПолитика доверия применяется шире, а поведение npm становится предсказуемее
Для глобальных установок улучшены подсказки с --allow-scriptsРазработчик быстрее понимает, почему npm предупреждает о непроверенных скриптах

Для обычного проекта это означает более ясный переход от модели «все install-скрипты запускаются автоматически» к модели, где доверие задаётся явно. Такой подход особенно полезен в рабочих репозиториях, где зависимости обновляются через Dependabot, Renovate или внутренние CI-процессы.

approve-scripts и deny-scripts стали удобнее для автоматизации

Команды npm approve-scripts и npm deny-scripts постепенно превращаются в рабочий инструмент для подготовки проектов к будущим ограничениям. Первая помогает разрешить запуск скриптов у доверенных пакетов, вторая — зафиксировать запрет для остальных.

В npm 11.17.0 важна доработка JSON-вывода. Когда команда используется человеком в терминале, формат вывода часто не критичен. В CI/CD ситуация другая: результат может читать скрипт, проверка pull request или внутренний security-инструмент. Невалидный JSON ломает такую цепочку, а корректный машинный вывод делает настройку политики воспроизводимой.

Ещё одна полезная деталь — обработка аргументов с точками и версиями. В npm-пакетах часто встречаются сложные имена, scoped-пакеты, версии и служебные обозначения. Чем точнее команды понимают такие аргументы, тем меньше ручных обходных решений понадобится при настройке политики для больших проектов.

npm 11.17.0 учитывает сценарии с локальными ссылками и удалёнными tarball

Релиз также исправляет несколько случаев, где новая модель разрешений могла вести себя неполно или неодинаково.

npm 11.17.0 распознаёт allowScripts для локальных link-зависимостей. Это важно для монорепозиториев, локальной разработки пакетов и рабочих пространств, где часть зависимостей подключается через ссылки, а не скачивается из реестра.

Отдельная доработка касается проверки пути реестра для allow-remote tarball-пакетов. Такие зависимости устанавливаются не по обычному имени из npm registry, а по URL на архив. Это удобно для некоторых внутренних процессов, но требует дополнительной осторожности: источник архива должен быть понятен и контролируем.

В Arborist, библиотеке npm для построения дерева зависимостей, обновлены сценарии для удалённых tarball, git-ссылок, вложенных file:-зависимостей и linked strategy. Эти изменения в основном заметят разработчики инструментов, администраторы CI и команды, у которых установка зависимостей устроена сложнее обычного npm install.

Публикация пакетов получила исправление для script-shell

В npm 11.17.0 исправлена передача script-shell в lifecycle hooks при публикации. Lifecycle hooks — это сценарии, которые npm запускает на определённых этапах, например при подготовке или публикации пакета.

Для большинства пользователей это будет незаметная техническая правка. Для мейнтейнеров пакетов она важнее: если проект явно задаёт shell для выполнения скриптов, npm должен учитывать эту настройку не только при установке, но и в связанных процессах публикации. Такое поведение снижает риск различий между локальной машиной, CI и release-пайплайном.

npm v12 делает npm 11.17.0 промежуточным этапом подготовки

Контекст релиза лучше понятен на фоне анонса GitHub о будущих изменениях npm v12. GitHub сообщил, что npm v12 планируется выпустить в июле 2026 года, а ключевые изменения будут связаны с безопасностью npm install.

В npm v12 install-скрипты зависимостей должны перейти к более строгой модели разрешений. Также ожидаются изменения в поведении Git-зависимостей и удалённых URL-зависимостей. GitHub прямо указывает, что предупреждения и инструменты подготовки доступны уже в npm 11.16.0 и новее.

На этом фоне npm 11.17.0 выглядит как практическая доводка переходного периода. Разработчики могут запускать обычную установку зависимостей, смотреть предупреждения, проверять список пакетов со скриптами и постепенно фиксировать политику в package.json.

Обновление полезно командам с CI/CD и строгими правилами безопасности

npm 11.17.0 особенно интересен проектам, где установка зависимостей проходит автоматически: в GitHub Actions, GitLab CI, Jenkins, Docker-сборках и внутренних пайплайнах. Именно там install-скрипты могут запускаться без участия человека, а ошибка в политике доверия быстро превращается в проблему для всей цепочки сборки.

Для небольших проектов релиз тоже имеет смысл. Проверка approve-scripts заранее показывает, какие зависимости пытаются запускать код при установке. Даже если команда пока не готова включать строгую политику, такой список помогает понять, где в проекте есть потенциально чувствительные места.

Отдельно стоит отметить новую настройку min-release-age-exclude. Она связана с политикой минимального возраста релиза и позволяет исключать отдельные пакеты из такого ограничения. Это полезно в сценариях, где проект хочет задерживать установку совсем свежих версий ради снижения риска supply chain-атак, но при этом должен быстро обновлять доверенные внутренние или критичные пакеты.

Практическое значение npm 11.17.0 заключается в подготовке к более строгой установке зависимостей

npm 11.17.0 показывает направление развития npm CLI. Установка зависимостей в JavaScript всё заметнее смещается к явному доверию: какие скрипты можно запускать, какие источники разрешены, какие исключения зафиксированы в проекте.

Сейчас для команд, поддерживающих production-сервисы, идеальное время проверить проект на npm 11.17.0. Это позволит увидеть предупреждения и понять, какие пакеты нуждаются в install-скриптах. К выходу npm v12 такая предварительная подготовка поможет избежать неожиданных сбоев в сборках и сделает политику зависимостей более прозрачной.

При использовании материалов сайта необходимо указывать ссылку на TGLand.ru. Если вы копируете фрагменты текста в интернете, прямая гиперссылка, доступная для индексации поисковыми системами, должна быть размещена в начале материала.

Вам также может понравиться