Как проверить результат `npm publish` без фактической публикации в NPM?

Одна из распространенных проблем, с которыми я сталкиваюсь, заключается в том, что иногда мой файл.npmignore слишком агрессивен, и я игнорирую файлы, которые я действительно хочу включить в архив 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, может не хватить, чтобы выполнить полный тест. Но, возможно, если мы скопируем все тестовые файлы (включая приборы и т. Д.), Когда мы copy_test_stuffэто может сработать?

Источник

6 ответов

Решение

Я создал решение этой проблемы. Вот проект: 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 и использование "files" означает, что вы можете не включить файлы, необходимые для публикации.

Источник

(Ответ 2019)

Просто беги

npm pack

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

Источник

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

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

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

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

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

+nohup npx verdaccio@2.7.2 &>$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 npm-cli-login@0.0.10 -u user -p password -e user@example.com -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 а затем они проводят испытания против вердаччо. Когда все готово, они публикуют на вердаччо. Как последний шаг, позже в том же файле они выбирают пакеты со своим собственным приложением.

pnpm

Они создали проект https://github.com/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, они готовят вердаччо и запускают тест как последний шаг. Я не могу вдаваться в подробности, так как видел это лишь поверхностно. Но я знаю, что он делает.

Мозилла Нейтрино

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

+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/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/

Источник

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

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

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

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

Источник

Ссылаясь на документы npm:

[--dry-run] Начиная с [email protected] , все ли публикации будут выполняться, кроме фактической публикации в реестре. Сообщает детали того, что было бы опубликовано.

По аналогии с --dry-run смотрите пакет npm, который определяет файлы, которые нужно включить, и упаковывает их в архив для загрузки в реестр.

https://docs.npmjs.com/cli/v6/commands/npm-publish#description

Источник

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

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

npm install . -g
Источник
Другие вопросы по тегам