Содержание
Коротко
npm и pnpm представили staged publishing — механизм, при котором версия пакета сначала попадает в registry в «черновом» состоянии, проходит проверки, и только потом становится доступной для установки по умолчанию. В JavaScript Weekly #787 это подаётся как ответ на цепочку инцидентов supply chain: меньше шансов, что сломанный или вредоносный tarball мгновенно разойдётся по миллионам npm install.
Что произошло
Классический npm publish делает версию сразу резолвимой: любой, кто запросит ^1.2.0 в ближайшие секунды, может получить только что залитый артефакт. Ошибка в CI, компрометация токена или злонамеренный maintainer — и инцидент масштабируется быстрее, чем команда успевает откатить тег.
Staged publishing разрывает этот момент. Пакет публикуется в промежуточном состоянии: его можно протестировать по прямой ссылке или внутреннему пайплайну, сравнить checksum, прогнать smoke-тесты потребителей — и лишь затем «продвинуть» до публичной видимости. Для монорепо и команд с жёстким compliance это ближе к blue-green деплою, чем к одношаговому выкладу.
Параллельно в экосистеме:
- pnpm 11.3 — политики доверия через
trustLockfile, новые команды управления пакетами; - npm 12.0 — в стадии prerelease, с расширенными возможностями registry;
- на периферии выпуска Firefox 151 добавил Web Serial (подключение JS к железу), Storybook 10.4 — поддержку TanStack React и сложных сетапов.
Для темы supply chain staged publishing — центральный сигнал выпуска #787; остальное контекст недели, а не одна связанная история.
Почему это важно
Атаки на npm не новость: подмена имён пакетов, захват прав сопровождающего, вредоносные postinstall-скрипты. Организации отвечают lockfile, npm audit, provenance и задержками на обновление мажоров. Staged publishing бьёт в другую точку — окно между публикацией и массовым потреблением.
Если registry даёт паузу, у security-команды и release-инженера появляется время:
| Этап | Что даёт staged publishing |
|---|---|
| До продвижения | Установка только по явной версии/каналу, не через диапазон |
| Проверка | CI потребителей, сравнение размера tarball, сканирование |
| После продвижения | Обычный semver-резолв для всех клиентов |
Оно не заменяет двухфакторную аутентификацию на аккаунте сопровождающего и не лечит скомпрометированную рабочую машину, но снижает масштаб последствий ошибочного релиза.
На практике
- Следите за документацией npm/pnpm — точные команды поэтапной публикации и продвижения могут отличаться между менеджерами; зафиксируйте во внутреннем регламенте.
- Встройте в CI — после публикации в черновом режиме гоняйте интеграционные тесты зависимого сервиса; продвигайте версию только при зелёном пайплайне.
- pnpm trustLockfile — согласуйте с политикой доверия пакетам: кто может попадать в lockfile без ручного approve.
- Потребители — если вы критичный потребитель в цепочке, не полагайтесь только на «свежий» диапазон версий; закрепляйте версии и используйте задержку обновлений (канареечное зеркало registry).
- npm 12 prerelease — тестируйте на staging registry до миграции продакшн-пайплайна публикации.
Для небольших OSS-проектов staged publishing может показаться избыточным; для пакетов с миллионами загрузок в неделю — разумный следующий слой после provenance.
Итог
Поэтапная публикация — признание того, что релиз npm-пакета — это продакшн-деплой, а не формальность после merge. В связке с lockfile-политиками pnpm и зрелостью npm 12 экосистема движется к более контролируемой цепочке поставки. Имеет смысл заложить staged шаг в release checklist, пока это опционально — потом станет ожиданием enterprise-потребителей.