pnpm 10.16

12 сентября 2025 · 3 мин чтения

Незначительные изменения

Новая настройка для отложенных обновлений зависимостей

Для снижения риска установки скомпрометированных версий пакетов вводится настройка minimumReleaseAge, которая задерживает установку недавно выпущенных зависимостей. Например, minimumReleaseAge: 1440 разрешает установку только пакетов, выпущенных не менее дня назад.

Исключения можно указать в minimumReleaseAgeExclude:

minimumReleaseAgeExclude:
  - webpack

Расширенная фильтрация зависимостей с помощью функций-поисковиков

Добавлена поддержка finders в .pnpmfile.cjs. Теперь можно искать зависимости не только по имени, но и по другим свойствам, например, по наличию определённой версии React в peerDependencies:

module.exports = {
  finders: {
    react17: (ctx) => {
      return ctx.readManifest().peerDependencies?.react === "^17.0.0";
    },
  },
};

Использование:

pnpm why --find-by=react17

Функции могут возвращать дополнительную информацию для вывода.

Исправления

• Устранено предупреждение о устаревании при запуске в Node.js 24.
• Добавлена проверка на точную версию semver для nodeVersion.
• Исправлена возможность публикации .tar.gz файлов через pnpm publish.
• Прерывание процесса Ctrl-C теперь возвращает ненулевой код выхода.

• Пользователи обсуждают стратегии защиты от вредоносных обновлений пакетов, включая задержку обновлений на несколько дней или месяцев и выборочное обновление только критических пакетов.
• Поднимается вопрос о том, как рассчитывается возраст пакета: важно использовать дату публикации в реестре, а не предоставленную автором, чтобы избежать подделки.
• Предлагаются альтернативные решения, такие как система разрешений для пакетов (à la Deno), разрешение зависимостей по хешу, а не по имени, и автоматизированный анализ кода ИИ перед публикацией.
• Отмечается, что подобные функции уже реализованы или разрабатываются в других менеджерах пакетов (Yarn, uv, Bun, npm-check-updates), и обсуждаются технические детали их реализации.
• Указывается на проблемы экосистемы npm: большой размер node_modules, высокая частота обновлений и автоматическое обновление минорных версий по умолчанию.
• Обсуждается роль автоматизированного сканирования новых пакетов security-компаниями как основного механизма обнаружения угроз, который может быть эффективнее индивидуальных задержек.
• Подчёркивается, что семантическое версионирование не всегда идеально соблюдается, и даже минорные обновления могут ломать совместимость, создавая риски при автоматическом обновлении.

Атака на поставки @ctrl/tinycolor: разбор инцидента

Злоумышленник добавил вредоносный workflow в GitHub Actions общего репозитория и похитил npm-токен с правами публикации. С помощью этого токена были опубликованы вредоносные версии 20 пакетов, включая @ctrl/tinycolor.

Мой аккаунт GitHub и репозиторий @ctrl/tinycolor не были скомпрометированы напрямую. Не использовался фишинг, на моём компьютере не устанавливались вредоносные пакеты. GitHub и npm оперативно отреагировали, удалив зловредные версии. Я выпустил чистые версии пакетов для очистки кэшей.

Как это произошло

Раньше я участвовал в проекте angulartics2 — общем репозитории, где у нескольких человек были права администратора. Там остался секрет GitHub Actions — npm-токен с широкими правами на публикацию.

Злоумышленник принудительно отправил ветку Shai-Hulud в angulartics2 с вредоносным workflow. Workflow запустился сразу после отправки (без проверки, так как у collaborator были права администратора) и украл npm-токен. С помощью украденного токена атакующий опубликовал вредоносные версии 20 пакетов.

Планы на будущее

Сейчас я использую semantic-release с GitHub Actions для публикации. Моя цель — перейти на Trusted Publishing (OIDC) в npm, чтобы полностью отказаться от статических токенов. Однако интеграция с semantic-release ещё в разработке.

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

Я планирую и дальше использовать pnpm, который блокирует неавторизованные postinstall-скрипты, и изучу новую настройку minimumReleaseAge.

Пожелания к системе публикации

В идеале хотелось бы иметь в npm единый переключатель для принудительного использования Trusted Publishing (OIDC) для всех моих пакетов. Такой же переключатель блокировал бы любые релизы без provenance, обеспечивая безопасность на уровне аккаунта. Также хотелось бы иметь встроенную поддержку semantic-release с OIDC и provenance, чтобы статические токены больше не требовались.

Кроме того, было бы удобно иметь безопасный вариант публикации с подтверждением человека прямо в интерфейсе GitHub: защищённый workflow_dispatch, использующий 2FA GitHub для удовлетворения требованиям двухфакторной аутентификации без необходимости публиковать со своего компьютера.

• Предлагается использовать ручные релизы и многоэтапные проверки для публикации пакетов вместо полной автоматизации CI/CD.
• Обсуждаются недостатки долгоживущих токенов и предлагается использовать Trusted Publishing с короткоживущими токенами или OIDC.
• Поднимается вопрос о необходимости встроенной MFA (двухфакторной аутентификации) для подтверждения публикации в CI-системах.
• Предлагается разделить процесс на загрузку пакета и его публикацию для пользователей, чтобы повысить контроль.
• Обсуждается идея использования подписей нескольких авторов или проверки подписей коммитов для обеспечения безопасности.
• Отмечается сложность настройки безопасных машинно-машинных потоков (OIDC) и необходимость более простых решений.
• Упоминается, что многие разработчики игнорируют вопросы безопасности до момента взлома и необходимы системные изменения.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

Доверие к случайному коду из интернета — социальная болезнь программистов.

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).

• Контекст = память агента
  Добавляйте только релевантные файлы. Помещайте их в context/ и docs/, укажите агенту читать README.md этих папок и самостоятельно выбирать нужные.
  Пример вставки в промпт:

  - При старте выведи список файлов в context/ и docs/
  - Прочитай README.md каждой папки
  - Используй только нужные
  

  Экономит токены и деньги.

• Контекст «на месте»
  Если агент постоянно ошибается (например, пишет тесты на Jest вместо Vitest), вставьте напоминание прямо в файл:

  // Проект использует vitest и cypress
  // Не использовать Jasmine/Jest
  // Запуск: pnpm test
  

• Модель и агент
  Для сложных задач берите Claude Sonnet. Пробуйте Claude Code и Roo Code — они сами подтягивают файлы проекта.
  Активные пользователи → оплата по факту; редкие → бесплатные чат-боты.

• Не «кодинг», а «создание»
  Пишите документацию в context/ (для разработки) и docs/ (для пользователей) и заставляйте агента обновлять их после каждого значимого изменения.

• Итог
  Это не единственный путь к успеху, а лишь то, что помогло мне — любителю — довести проект до рабочего состояния.

• LLM-агенты склонны к избыточной абстракции и «улучшениям» — нужно явно ограничивать их свободу.
• Помогает задавать агенту до 10 уточняющих вопросов, чтобы сузить контекст и избежать ошибок.
• Для тяжёлых пользователей дешевле подписка Claude Code, чем оплата за токены по API.
• Агенты могут отключать тесты вместо их починки — поведение зависит от языка и фреймворка.
• Контекст лучше держать прямо в тестах или использовать под-агентов и файлы AGENTS.md.
• Краткие, точные промпты (в стиле RFC) часто работают лучше длинных и «разговорных».

AGENTS.md — открытый формат инструкций для AI-агентов, используется >20k проектов.
Это «README для агентов»: единое место для команд сборки, тестов, стиля кода и прочих деталей, которые не нужны людям, но критичны для ИИ.

## Команды
- `pnpm i` — зависимости  
- `pnpm dev` — запуск  
- `pnpm test` — тесты  

## Стиль
TypeScript strict, одинарные кавычки, без точек с запятой, функциональный стиль.

Зачем отдельный файл?

• README — для людей, AGENTS.md — для агентов.
• Не загромождает документацию.
• Один формат подходит всем: Codex, Amp, Jules, Cursor, Factory, RooCode и др.

Как использовать

1. Создайте AGENTS.md в корне.
2. Добавьте: обзор проекта, команды сборки/тестов, стиль, security, правила PR.
3. В монорепозиториях кладите отдельные файлы в каждый пакет; агент читает ближайший.

Примеры

• openai/codex
• apache/airflow
• temporalio/sdk-java
• PlutoLang/Pluto

Ещё 20k примеров

• Участники спорят, нужен ли отдельный AGENTS.md или достаточно README/CONTRIBUTING.
• Одни считают файл полезной «эргономичной ручкой» — люди охотнее пишут инструкции для ИИ, чем для людей.
• Другие критикуют: это не формат, а просто соглашение; нет импортов, иерархии, стандарта между агентами.
• Практики варьируются: кто-то хранит роль-файлы в .agent, кто-то делает симлинки на CLAUDE.md, кто-то использует .agdocs/guides/.
• Общий вывод: AGENTS.md пока временный костыль, пока ИИ не научится полноценно читать человеческую документацию.