Как протестировать результат "npm publish", не публиковав его в NPM?

Одна общая проблема, которую я имею, заключается в том, что иногда мой файл.npmignore слишком агрессивен, и я игнорирую файлы, которые я на самом деле должен включить в tar-архив NPM.

Мой вопрос: есть ли способ проверить результаты публикации NPM, без фактического опубликования в NPM?

Я думаю, что-то вроде этого. Предполагая, что у меня есть локальный пакет NPM с именем пакета "foo"

set -e;
local proj="bar";
local path_to_foo="."
mkdir -p "$HOME/.local.npm"
npm --tarball -o "$HOME/.local.npm"  # made up command, but you get the idea
(
  cd "$HOME/.temp_projects"
  rm -rf "$proj"
  mkdir "$proj"
  cd "$proj"
  npm init -f
  npm install "$path_to_foo"
)
copy_test_stuff -o "$HOME/.temp_projects/bar"

cd "$HOME/.temp_projects/bar"
npm test

Я не думаю, что это сработает. Поскольку все, что мы включаем в NPM, публикуем tarball, может не хватить для полного тестирования. Но может быть, если мы скопируем все тестовые файлы (в том числе светильники и т.д.), Когда мы будем делать copy_test_stuff, это может сработать?

Ответы

Ответ 1

Я создал решение этой проблемы. Здесь проект: https://github.com/ORESoftware/r2g

README отлично справляется с этим, но, в общем, он использует npm pack для создания tarball, а затем в другом локальном проекте NPM вы используете npm install --production/path/to/tarball.tgz для использования исходного NPM проект, который вы хотите проверить.

Я также включил идею @Zoltan Kochan из своего ответа ниже, которая предназначена для npm pack проекта X, а затем установить этот tarball как зависимость от проекта X (привязка проекта к себе). Затем вы можете повторно использовать набор тестов для тестирования самого проекта в его опубликованной форме.

Преимущества, по крайней мере, в три раза - во-первых, вы не позволяете какой-либо настройке в.npmignore сделать так, чтобы в вашем опубликованном пакете отсутствовали файлы, которые вам нужны. А во-вторых, вы вынуждаете себя проверять его как зависимость от другого проекта, а не просто тестировать проект непосредственно в рамках одного проекта. В-третьих, вы используете флаг --production с npm install чтобы узнать, есть ли у вас все зависимости, необходимые для его запуска в процессе производства.

Когда ваша библиотека тестируется на Jenkins/Travis/Appveyor и т.д., Она обычно находится в формате контроля версий, а не в опубликованном формате NPM. В основном это до.npmignore, и что.npmignore не учитывает ваш проект. Кроме того, некоторые люди используют свойство "files" в package.json, а использование "файлов" означает, что вы не можете включить файлы, которые вам нужны для публикации.

Ответ 2

Я уточню свой комментарий, который я разместил на раннем этапе, (спасибо Александру Миллсу).

Я verdaccio, поэтому, я внимательно слежу за тем, кто реализует и как verdaccio. Я опишу пары или примеры (в основном, e2e), которые я нашел и мог бы быть интересным или правильным ответом.

создает реагирующий-приложение

Безусловно, самая популярная интеграция. Позвольте мне дать вам какой-то контекст, они используют lerna и имеют несколько пакетов, которые необходимо проверить перед публикацией в основном реестре aka (npmjs). Я приведу здесь Дэн Абрамов, объясняющий причины использования реестра custon.

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

+nohup npx [email protected] &>$tmp_registry_log &
+# Wait for 'verdaccio' to boot
+grep -q 'http address' <(tail -f $tmp_registry_log)
+
+# Set registry to local registry
+npm set registry http://localhost:4873
+yarn config set registry http://localhost:4873
+
+# Login so we can publish packages
+npx [email protected] -u user -p password -e [email protected] -r http://localhost:4873 --quotes

 # Test local start command
 yarn start --smoke-test

+./tasks/release.sh --yes --force-publish=* --skip-git --cd-version=prerelease --exact --npm-tag=latest

Как вы видите, они используют verdaccio и вместо этого настраиваемый файл конфигурации, который они решили использовать для npm-cli-login а затем они запускают тесты против verdaccio. Когда все будет готово, они публикуются на verdaccio. В качестве последнего шага, позже в том же файле, они извлекают пакеты со своим собственным приложением.

pnpm

Они создали проект под названием pnpm-registry-mock, который представляет собой абстракцию, которая позволяет им запускать verdaccio перед запуском тестов.

 "pretest:e2e": "rimraf ../.tmp/ && rimraf node_modules/.bin/pnpm && pnpm-registry-mock prepare",
 "test:e2e": "preview --skip-prepublishOnly && npm-run-all -p -r pnpm-registry-mock test:tap",
 "test": "npm run lint && npm run tsc && npm run test:e2e",

В основном, используя сценарии npm, они готовят verdaccio и запускают тест как последний шаг. Я не могу вдаваться в подробности, потому что я видел это неглубоко. Но я знаю, что он делает.

Mozilla Neutrino

Это незавершенная работа, но здесь интересно также упомянуть.

+if [ "$PROJECT" == "all" ]; then
+  yarn link:all;
+  yarn validate:eslintrc;
+  yarn lint;
+  yarn build;
+  yarn test;
+else
+  yarn verdaccio --config verdaccio.yml & sleep 10;
+  yarn config set registry "http://localhost:4873";
+  npm config set registry "http://localhost:4873";
+  .scripts/npm-adduser.js;
+  yarn lerna publish \
+    --force-publish=* \
+    --skip-git \
+    --skip-npm \
+    --registry http://localhost:4873/ \
+    --yes \
+    --repo-version $(node_modules/.bin/semver -i patch $(npm view neutrino version));
+  yarn lerna exec npm publish --registry http://localhost:4873/;
+  PROJECT="$PROJECT" TEST_RUNNER="$TEST_RUNNER" LINTER="$LINTER" yarn test:create-project;
+fi

Опять же, тот же подход, проект строится, а затем verdaccio и публикуются все пакеты.

Babel.js

Я знаю, что Babel.js экспериментирует с тестированием дыма для Babel 6 и планирует интегрировать реестр с Babel 7. Я цитирую Генри Чжу в начале этого года, рассказывая о babel-smoke-tests в том же потоке приложения create-react-app.

Эксперимент называется babel-smoke-tests и babel-smoke-tests/scripts/test.sh - это ключевой файл для вас.

Здесь я вижу ту же структуру, что и другие проекты. Они запускают verdaccio а затем они делают свое дело.

START=$(cd scripts; pwd)/section-start.sh
END=$(cd scripts; pwd)/section-end.sh

$START 'Setting up local npm registry' setup.npm.registry
node_modules/.bin/verdaccio -l localhost:4873 -c verdaccio.yml &

export NPM_CONFIG_REGISTRY=http://localhost:4873/

NPM_LOGIN=$(pwd)/scripts/npm-login.sh

$NPM_LOGIN

$END 'Done setting up local npm registry' setup.npm.registry

scripts/bootstrap.sh

export THEM=$(cd them; pwd)

if [[ $SPECIFIC_TEST ]]; then
    scripts/tests/$SPECIFIC_TEST.sh
else
    scripts/tests/jquery.sh
    scripts/tests/react.sh
fi

Заворачивать

Прежде всего, я надеюсь, что мое небольшое исследование даст вам новые идеи, как решить вашу проблему. Я думаю, что npm pack решает некоторые проблемы, но издевательский реестр с использованием verdaccio который достаточно лёгкий и простой в использовании, может стать для вас реальным вариантом. Некоторые крупные проекты используются (или начинаются), используя их, и они придерживаются более или менее того же подхода. Итак, почему бы не попробовать? :)

https://www.verdaccio.org/

Ответ 3

У меня была такая же проблема, поэтому я создал пакет под названием package-preview. Что такое предварительный просмотр пакета:

  1. пакеты вашего пакета (это то, что делает npm перед публикацией)
  2. устанавливает ваш пакет во временном местоположении
  3. связывает пакет с вашим проектом node_modules

Это позволяет вам в основном требовать, чтобы пакет был зависимым от ваших тестов. Таким образом, в тестах "awesome-pkg", intead of require('../lib') вы пишете, require('awesome-pkg')

Я использую этот пакет во всех репозиториях pnpm в течение нескольких месяцев, и он работает очень хорошо. Я также опубликовал статью об этом пакете, в которой объясняются все различные ошибки, которые он может уловить: никогда не забывайте устанавливать зависимость

Ответ 4

(Ответ 2019)

Просто беги

npm pack

В npm 6 и выше это покажет, какие файлы будут загружены, и создаст tar-шар в текущем каталоге.

Ответ 5

Я вижу слишком много сложных ответов, но согласно документации, вам просто нужно установить локальный пакет глобально (потому что он будет установлен в другой каталог)

Перейдите в корневой каталог вашего модуля и выполните

npm install . -g