pnpm vs Lerna: фильтрация в многопакетном репозитории

Все слышали о Lerna, инструменте для управления проектами JavaScript с несколькими пакетами. Гораздо меньше разработчиков слышали о pnpm, быстром, экономном месте на диске диспетчере пакетов для JavaScript. И Lerna, и pnpm пытаются улучшить инструменты для многопакетных репозиториев (MPR). Для Лерны это было причиной творчества. Для pnpm поддержка MPR - это приятная бонусная функция, которая реализуется с помощью набора команд, называемых рекурсивными. Конечно, есть много различий между тем, как Лерна управляет многопакетным репо и pnpm. В этой статье я хочу сравнить один, казалось бы, простой аспект: фильтрацию.

Фильтрация в MPR важна, потому что во время разработки изменения в основном вносятся внутри одного или двух пакетов. Было бы бессмысленно запускать команды для всего репозитория, если бы были изменены только несколько пакетов.

Фильтрация в Лерне

Фильтрация в Лерне (по состоянию на v3.2.1) достигается следующими флагами:

  • scope - включать только пакеты с именами, соответствующими данному глобу.
  • include-filtered-dependents - Включить всех транзитивных зависимостей при выполнении команды независимо от --scope, --ignore или --since.
  • include-filtered-dependencies - включить все переходные зависимости при выполнении команды независимо от --scope, --ignore или --since.
  • ignore - Исключить пакеты с именами, соответствующими данному глобу.
  • private - Включить частные пакеты. Передайте --no-private, чтобы исключить частные пакеты.
  • since - включать только пакеты, которые были обновлены после указанного [ref]. Если ссылка не передана, по умолчанию используется самый последний тег.

Эти флаги делают фильтрацию в Лерне достаточно мощной. Однако их довольно сложно набрать. Допустим, вы скачали репозиторий и хотите работать только с login-page компонентом. Вы хотите запустить установку login-page и любой из его зависимостей:

lerna bootstrap --scope login-page --include-filtered-dependencies

Или, может быть, вы изменили компонент с именем site-header и хотите запустить тесты для всех зависимых пакетов:

lerna run test --scope site-header --include-filtered-dependents

Эти флаги не только сложно набрать, но также сложно запомнить и легко перепутать.

Фильтрация в pnpm

В отличие от Lerna, pnpm использует специальный синтаксис селектора пакетов для ограничения своих команд. Поэтому вместо запоминания набора длинных имен флагов вам следует помнить только очень простой для запоминания синтаксис селектора.

Начиная с версии 2.15.0 pnpm поддерживает следующие селекторы:

  • <pattern> - ограничивает область действия именами пакетов, соответствующими заданному шаблону. Например: foo, @bar/*
  • <pattern>... - включает все прямые и косвенные зависимости совпадающих пакетов. Например: foo...
  • ...<pattern> - включает всех прямых и косвенных зависимых от совпадающих пакетов. Например: ...foo, ...@bar/*
  • ./<directory> - включает все пакеты, находящиеся в данном подкаталоге. Например: ./components
  • . - включает все пакеты, находящиеся в текущем рабочем каталоге.

Эти фильтры могут быть указаны либо с помощью флага --filter, либо после -- в конце команды.

Примечание. Начиная с v2.15.0, фильтры после -- не поддерживаются в run, exec, test

Итак, если вы хотите загрузить login-page и все его зависимости, это способ сделать это с помощью pnpm:

pnpm recursive install -- login-page...

И если вы хотите запустить тесты site-header и всех его зависимостей, используйте селектор ...<pattern>:

pnpm recursive test --filter ...site-header

Конечно, вы можете комбинировать столько селекторов, сколько захотите:

pnpm recursive update -- ...site-header login-page... ./utils @style/*

Приведенная выше команда обновляет зависимости в:

  • site-header
  • иждивенцы site-header
  • login-page
  • зависимости login-page
  • все пакеты, которые находятся в каталоге utils
  • все пакеты из области @style

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

Если вы еще не слышали о pnpm, я рекомендую также прочитать Flat node_modules - не единственный способ, который объясняет уникальную структуру node_modules, созданную pnpm.

Шпаргалка