15 октября 2026 года команда npm опубликовала версию 12.2.1 с исправлением механизма allowScripts для проектов, использующих install-strategy=linked. Раньше подтверждение запуска скриптов могло создавать в package.json неправильные записи с путями к внутреннему хранилищу зависимостей. В результате npm не распознавал выданное разрешение при установке пакета.
Из-за ошибки allowScripts одобренные скрипты оставались заблокированными
В npm 12 скрипты зависимостей, запускаемые во время установки, по умолчанию требуют явного разрешения. Речь идёт о командах preinstall, install и postinstall, с помощью которых библиотеки могут, например, готовить компоненты для работы на конкретной системе. Политика allowScripts хранится в package.json проекта и указывает, каким пакетам разрешено выполнять такие действия.
Проблему обнаружили при использовании особой схемы размещения зависимостей — install-strategy=linked. 1 сентября пользователь GitHub сообщил, что после одобрения скриптов npm записывает длинные ключи вида file:../../../.../node_modules/... и иногда дублирует их. В отчёте приводились примеры с пакетами esbuild и vue-demi.
Ожидаемая запись для пакета из реестра выглядит гораздо проще:
{
"allowScripts": {
"esbuild@0.28.2": true
}
}Такая запись разрешает установочные скрипты определённой версии esbuild. Ошибочные записи с путями в node_modules/.store не совпадали с идентификатором пакета при следующей установке. Из-за этого разрешение формально присутствовало в конфигурации, но npm продолжал пропускать соответствующие скрипты.
Почему npm путал ссылки в node_modules с самими пакетами
По умолчанию npm использует стратегию hoisted: старается размещать общие зависимости ближе к корню каталога node_modules. При linked пакеты находятся во внутреннем каталоге node_modules/.store, а нужные места дерева зависимостей соединяются с ними символическими ссылками.
Такая изоляция помогает обнаруживать незаявленные зависимости. Если пакет пытается подключить библиотеку, которой нет в его собственном списке зависимостей, ссылочная структура может выявить ошибку раньше публикации приложения.
Разработчики npm выяснили, что при одобрении скрипта программа воспринимала несколько ссылок на один пакет как отдельные объекты. Для каждой ссылки создавался собственный ключ с относительным путём. Одновременно механизм проверки не всегда мог восстановить подлинное имя и версию пакета из реестра.
Ошибка затрагивала и сопутствующие команды. npm install-scripts ls мог неверно определять пакеты без разрешения, а npm install-scripts prune — считать действующие записи устаревшими. Получалась несогласованность между списком разрешений и тем, как установщик на самом деле проверял право запуска скриптов.
npm 12.2.1 восстанавливает корректную проверку разрешений
Исправление, включённое в релиз под номером GitHub PR #9941, меняет обработку ссылочных объектов. При сопоставлении команды с пакетом npm теперь опирается на сам пакет и его проверяемую идентичность в реестре. Внутренние пути .store больше не подставляются вместо имён пакетов при формировании правил allowScripts.
После исправления ожидается согласованная работа трёх операций:
approveзаписывает разрешение для пакета по его имени и, когда доступна подтверждённая версия, закрепляет его за этой версией;lsопределяет пакеты, чьи установочные скрипты ещё не покрыты правилами;pruneочищает устаревшие записи, сохраняя действующие разрешения.
Во время проверки исправления обнаружился дополнительный пограничный случай. Если информация о версии в скрытом lockfile отсутствует или устарела, очистка не должна удалять действующий запрет вроде canvas@1.0.0: false, оставляя при этом более широкое разрешение canvas: true. Этот сценарий тоже учтён в исправлении: при неопределённой версии запрет сохраняется.
Таким образом, исправлена как сама запись разрешений, так и их последующая проверка и очистка.
Какие проекты затрагивает исправление linked-установки
Изменение адресовано прежде всего проектам, где в .npmrc установлено install-strategy=linked или такая стратегия передаётся при установке пакетов. При стандартной стратегии hoisted описанное поведение не было причиной исходного отчёта.
Проверить применяемую стратегию и текущий список пакетов с неподтверждёнными скриптами позволяют документированные команды npm:
npm config get install-strategy
npm install-scripts lsДля просмотра правил, которые команда очистки сочтёт устаревшими, предусмотрен режим:
npm install-scripts prune --dry-runЭти команды сами по себе не запускают установочные скрипты. Команда approve изменяет политику allowScripts в package.json; выполнение разрешённых скриптов происходит при соответствующих операциях установки или пересборки.
В обновлении 12.2.1 также изменены версии нескольких внутренних зависимостей npm, включая undici до 6.29.0, http-cache-semantics до 4.3.0 и @npmcli/arborist до 10.0.4. Отдельных заявлений о приросте производительности или новых пользовательских командах в примечаниях к этому релизу нет.
Исправление делает политику install-скриптов предсказуемее
В официальном changelog npm 12.2.1 указана дата 14 октября 2026 года, а страница релиза на GitHub была опубликована 15 октября. Исправление закрывает ошибку, описанную в issue #9939 ещё 1 сентября.
Для проектов со стратегией linked теперь устранено расхождение между записью разрешения в package.json и его распознаванием во время установки. Сохранение точечных запретов при очистке правил дополняет это изменение: даже при неполных данных о версии пакета npm не должен превращать существующий запрет в разрешение.
