node.js - last - ¿Cómo probar un resultado de `npm publish`, sin publicar realmente en NPM?
npm registry (4)
Elaboraré mi comentario que publiqué Earler, (gracias Alexander Mills).
Soy un contribuidor de verdaccio , por lo tanto, sigo de cerca a quiénes están implementando y cómo hacerlo. Describiré parejas o ejemplos (e2e principalmente) que he encontrado y que pueden ser interesantes o como una respuesta válida.
crear-reaccionar-aplicación
De lejos, la integración más popular. Permítame darle un poco de contexto, están usando lerna y tienen varios paquetes que necesitan probar antes de publicar en el registro principal aka ( npmjs ). Citaré aquí a Dan Abramov explicando sus razones para usar un registro de custon.
El guión es autoexplicativo, pero permítame resaltar algunas partes.
+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
Como puede ver, están ejecutando verdaccio y en su lugar un archivo de configuración personalizado que han decidido usar npm-cli-login y luego ejecutan las pruebas contra verdaccio. Cuando todo está listo, publican en verdaccio. Como último paso, más adelante en el mismo archivo, obtienen paquetes con su propia aplicación.
pnpm
Han creado un proyecto llamado pnpm-registry-mock que es una abstracción que les permite ejecutar verdaccio antes de ejecutar las pruebas.
"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",
Básicamente, utilizando npm scripts preparan verdaccio y ejecutan la prueba como último paso. No puedo entrar demasiado en los detalles, ya que solo lo he visto superficialmente. Pero sé lo que hace.
Mozilla Neutrino
Este es un trabajo en progreso , pero, también es interesante mencionar aquí.
+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
Nuevamente, se está construyendo el mismo enfoque, se está ejecutando el proyecto y luego se está ejecutando verdaccio y se publican todos los paquetes.
Babel.js
Sé que Babel.js ha estado experimentando con una prueba de humo para Babel 6 y tiene planes de integrar un registro con Babel 7 . Cito a Henry Zhu a principios de este año hablando de babel-smoke-tests en el mismo hilo de la aplicación create-react-app .
El experimento se llama babel-smoke-tests y babel-smoke-tests/scripts/test.sh es el archivo clave para usted.
Aquí veo el mismo patrón que otros proyectos. Están lanzando verdaccio y luego hacen sus cosas.
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
Envolver
En primer lugar, espero que mi pequeña investigación le dé nuevas ideas sobre cómo abordar su problema. Creo que npm pack resuelve algunos problemas, pero burlarse de un registro con verdaccio que es bastante ligero y sencillo de usar podría ser una opción real para ti . Algunos grandes proyectos están siendo (o están empezando) usándolo y siguen más o menos el mismo enfoque. Entonces, ¿por qué no intentarlo? :)
Un problema común que tengo es que a veces mi archivo .npmignore es demasiado agresivo, e ignoro los archivos que realmente incluiré en el archivo NPM.
Mi pregunta es: ¿hay alguna manera de probar los resultados de la publicación de NPM, sin publicar realmente en NPM?
Estoy pensando algo como esto. Suponiendo que tengo un paquete NPM local con el nombre del paquete "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
No creo que esto funcione. Debido a lo que sea que incluyamos en el archivo publicitario NPM, es posible que no tengamos suficiente para realizar la prueba completa. Pero tal vez si copiamos todos los archivos de prueba (incluidos los accesorios, etc.) cuando hacemos copy_test_stuff , ¿podría funcionar?
He creado una solución a este problema. Aquí está el proyecto: https://github.com/ORESoftware/r2g
README hace un buen trabajo explicándolo, pero en resumen, básicamente utiliza el npm pack para crear un npm pack , y luego en otro proyecto NPM local, utiliza npm install --production /path/to/tarball.tgz para usar el NPM original Proyecto que desea probar.
También incorporé la idea de @Zoltan Kochan de su respuesta a continuación, que es npm pack un proyecto X, y luego instalar ese tarball como una dependencia del proyecto X (vincular un proyecto a sí mismo). Luego puede reutilizar el conjunto de pruebas para probar el proyecto en sí mismo, en su forma publicada.
Las ventajas son, al menos, triples: en primer lugar, no permite que una configuración imprecisa en .npmignore haga que el paquete publicado carezca de los archivos que necesita. Y, en segundo lugar, se obliga a probarlo como una dependencia de otro proyecto y no solo a probar el proyecto directamente dentro del mismo proyecto. En tercer lugar, está utilizando el indicador npm install with npm install para ver si tiene todas las dependencias que necesita para ejecutarlo en producción.
Cuando su biblioteca se prueba en Jenkins / Travis / Appveyor, etc., generalmente está en el formato de control de versiones, no en el formato publicado de NPM. Principalmente esto se debe a .npmignore, y lo que .npmignore omite en su proyecto. Además, algunas personas usan la propiedad "files" en package.json, y el uso de "archivos" significa que podría no incluir los archivos que necesita para publicar.
Tuve exactamente el mismo problema, así que creé un paquete llamado package-preview . Lo que hace la vista previa del paquete es:
- Paquetes de su paquete (es lo que hace npm antes de publicar)
- instala tu paquete en una ubicación temporal
- vincula el paquete a los node_modules de tu proyecto
Esto le permite básicamente requerir el paquete como una dependencia en sus pruebas. Por lo tanto, en las pruebas de "awesome-pkg", en lugar de require(''../lib'') usted escribe require(''awesome-pkg'')
Utilizo este paquete en todos los repositorios de pnpm durante varios meses y funciona muy bien. También publiqué un artículo sobre este paquete que explica todos los diferentes errores que puede detectar: Nunca te olvides de instalar una dependencia
Veo demasiadas respuestas complicadas, pero de acuerdo con la documentación, solo necesita instalar su paquete local globalmente (porque se instalará en un directorio diferente)
Vaya al directorio raíz de su módulo y haga
npm install . -g