Чтобы проверить, что именно будет содержать общий пакет npm workspace при поставке, запустите его тесты из монорепозитория, упакуйте воркспейс, а затем установите полученный tarball в отдельный временный каталог потребителя на вашем Mac. Это позволяет выявить проблемы, скрытые локальной символической ссылкой npm workspace, такие как отсутствие скомпилированных файлов или неверная точка входа пакета. Этот процесс ничего не публикует в реестре.

1. Запустите собственные тесты пакета из корня воркспейса

Откройте Терминал и перейдите в корень монорепозитория — каталог, содержащий корневой package.json. Убедитесь, что пакет указан в корневой конфигурации workspaces и имеет собственный package.json. npm устанавливает настроенные воркспейсы в виде ссылок в корневой node_modules, поэтому запуск тестов оттуда может разрешать актуальный исходный код воркспейса. Параметр workspace позволяет выбрать пакет по его объявленному имени или каталогу. npm Workspaces

Запустите скрипт тестирования пакета по имени его воркспейса, подставив имя из его package.json:

npm run test --workspace=@acme/math

Если в пакете используется другое имя скрипта, используйте его. Если скрипт тестирования отсутствует, эта команда не сможет проверить его поведение; запустите проверки, которые фактически определены в проекте, например скрипты сборки или линтинга. Старайтесь не полагаться только на команду тестирования корневого уровня: такие команды npm, как test, выполняются в корне, если вы не указали воркспейс. npm Workspaces

2. Проверьте и создайте tarball пакета

Локальный тест воркспейса не доказывает, что файлы, необходимые потребителям, включены в пакет. Сначала просмотрите содержимое пакета выбранного воркспейса из корня монорепозитория:

npm pack --workspace=@acme/math --dry-run

Проверьте список файлов на наличие точки входа пакета, результатов сборки, объявлений типов и любых других файлов, которые должен предоставлять пакет. Настройки npm files, .npmignore и .gitignore влияют на содержимое; package.json, файлы README и лицензии входят в число тех, которые npm включает по умолчанию. Убедитесь, что main или exports указывают на файлы, которые попадут в архив. npm pack, package.json files and entry points

Когда список выглядит правильно, создайте реальный tarball во временном каталоге. Следующие команды используют стандартное экранирование macOS, совместимое с zsh, и сохраняют артефакт за пределами вашего репозитория:

scratch="$(mktemp -d "${TMPDIR:-/tmp}/workspace-package-check.XXXXXX")"
npm pack --workspace=@acme/math --pack-destination="$scratch"

Флаг --dry-run только сообщает, что именно упакует npm; он не создает архив. Вторая команда создает его, но не загружает в реестр. В документации npm команда npm pack описывается как создающая tarball и поддерживающая селектор воркспейса. npm pack

3. Установите архив в чистую папку потребителя

Найдите путь к архиву tarball, создайте отдельный каталог потребителя и установите архив туда. В этом примере предполагается, что во временный каталог был упакован только один tarball:

tarball="$(find "$scratch" -maxdepth 1 -name '*.tgz' -print -quit)"
consumer="$scratch/consumer"
mkdir -p "$consumer"
cd "$consumer"
npm init -y
npm install "$tarball"

Установка .tgz проверяет именно упакованный артефакт. Установка папки воркспейса или использование связанной зависимости монорепозитория могут вести себя иначе. npm install

Теперь протестируйте пакет через его публичную точку входа. Используйте фактическое имя пакета и небольшую проверку потребителя, подходящую для его API — например, выполните require или import пакета, а затем вызовите показательную экспортированную функцию. Запустите эту проверку из каталога потребителя, где пакет разрешается из только что установленного node_modules. Если проект публикует скомпилированный код, убедитесь, что сборка была запущена перед упаковкой; в противном случае в архиве могут отсутствовать файлы, даже если тесты во время разработки прошли успешно.

4. Диагностика ошибок перед публикацией

Если установка завершилась неудачей, убедитесь, что архив содержит package.json с полями name и version, затем изучите список файлов и проверьте, что настроенные точки входа присутствуют в tarball. Если не удается выполнить импорт, сравните формат модулей потребителя с параметрами type, main и exports пакета. Пакет может проходить тесты воркспейса, но падать здесь, поскольку эти тесты могут загружать исходные файлы напрямую или разрешать необъявленные зависимости из монорепозитория.

Если зависимостью является другой неопубликованный воркспейс, протестируйте также и планируемую схему релиза. Потребитель, устанавливающий один tarball, не получит автоматически исходный код соседнего воркспейса через связь монорепозитория. Убедитесь, что соседние пакеты опубликованы/доступны в совместимых версиях, либо используйте намеренную бандлированную или устанавливаемую конфигурацию. Эта процедура проверяет локальный упакованный пакет в текущей среде Mac/Node; она не может гарантировать корректное поведение во всех версиях Node, операционных системах или конфигурациях реестра.

Разумная точка завершения — успешное прохождение тестов воркспейса, корректный список файлов пакета и проверка потребителя, которая устанавливает и запускает tarball за пределами монорепозитория. Сохраните временный каталог, если вам нужно его изучить, или удалите его с помощью rm -rf "$scratch", предварительно убедившись, что переменная все еще указывает на созданный временный путь.

Источники