JavaScript

Ejecutar múltiples scripts npm (Creación de una librería JavaScript 8ª parte)

En esta octava y última entrega de la serie se va a explicar cómo ejecutar múltiples scripts npm para automatizar los procesos. Hasta ahora los scripts npm se ha utilizado para simplificar el lanzamiento de comandos. Reemplazados comandos más o menos complicados por un alias más fácil de recordar. Pero, es necesario lanzar múltiples comandos en un orden dado para conseguir repetir los pasos: medir la calidad del código, ejecutar las pruebas unitarias, obtener el grado de cobertura de las pruebas, compilar la librería y, finalmente, comprimir el archivo resultante para su distribución. En esta entrada se mostrará como utilizar el comando el módulo npm-run-all para ejecutar todos los comandos necesarios en un solo paso.

Además, al final de la entrada, se mostrará también un ejemplo de archivo .gitignore para el proyecto.

Esta entrada pertenece a la serie “Creación de una librería JavaScript” cuyo código se puede encontrar en la cuenta de GitHub de Analytics Lane. Serie compuesta por las siguientes entradas:

Instalación npm-run-all

El módulo npm-run-all se puede instalar, como todos los que hemos visto en la serie, mediante el comando npm. Para instalarlo y guardar las opciones en listado de dependencias se ha de ejecutar el comando.

npm install npm-run-all --save-dev

El motivo por el que va a utilizar este módulo en lugar de concatenar las instrucciones en la línea de comandos es conseguir que el script se puede utilizar tanto en UNIX como en Windows.

Lanzar múltiples comandos npm con npm-run-all

En el proceso de compilación de una librería es necesario llevar a cabo varios pasos. El primero es medir la calidad de código en búsqueda de errores, para lo que se usa jshint. Posteriormente se han de lanzar las pruebas unitarias y comprobar el grado de cobertura. Las herramientas para hacer esto son mocha y nyc. Finalmente es necesario compilar los archivos, con browserify, y comprimir el resultado, con uglifyjs. Los pasos que se han visto en las siete entradas anteriores de la serie.

Para cada uno de estos procesos ya se ha creado en su momento un script npm. Por el proceso completo requiere ejecutar los siguientes comandos en la terminal.

> npm run report
> npm run coverage
> npm run checkCoverage
> npm run build
> npm run minimize

Los cuales se pueden lanzar únicamente con el siguiente comando

npm-run-all report coverage checkCoverage build minimize

Proceso que se puede almacenar en un nuevo script npm al que se puede llamar deploy. Así para crear la librería solamente será necesario escribir.

npm run deploy

El archivo package.json

Una vez agregado este último script y modulo a archivo package.json este debería quedar similar al siguiente.

{
  "name": "jslane",
  "version": "1.0.0",
  "description": "A basic JavaScript library",
  "main": "index.js",
  "scripts": {
    "build": "browserify index.js --standalone jslane -o ./dist/jslane.js",
    "checkCoverage": "./node_modules/nyc/bin/nyc.js check-coverage --lines 95 --functions 95 --branches 95",
    "coverage": "./node_modules/nyc/bin/nyc.js --reporter=lcov npm test",
    "deploy": "./node_modules/npm-run-all/bin/npm-run-all/index.js report coverage checkCoverage build minimize",
    "minimize": "uglifyjs ./dist/jslane.js -o ./dist/jslane.min.js --compress --mangle",
    "report": "./node_modules/jshint/bin/jshint ./lib**/*.js ./tests**/*.js",
    "test": "./node_modules/mocha/bin/mocha tests/**/*test.js --ui tdd"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "chai": "^4.2.0",
    "chai-deep-closeto": "^0.1.1",
    "jshint": "^2.9.7",
    "mocha": "^5.2.0",
    "npm-run-all": "^4.1.5",
    "nyc": "^13.1.0"
  }
}

En este se puede observar que se han incluido la ruta absoluta a todos los módulos para evitar problemas.

Crear un repositorio Git

Ahora que se ha definido el flujo de trabajo, se debería de guardar el proyecto en un gestor de versiones. Para lo que se usará Git. En el proyecto hay múltiples carpetas que son resultados de los procesos, como los informes de cobertura, o los módulos de node. Los cuales no es necesario guardar. Para evitar que se guarde se puede crear un archivo .gitignore en el que se puede indicar estas carpetas.

Las carpetas que a omitir en el gestor de versiones son:

  • node_modules: los módulos de node.
  • .nyc_output: los resultados de nyc.
  • coverage: la carpeta donde istanbul guarda los resultados.
  • lib-cov: el informe de cobertura de las pruebas unitarias.

Por lo que se puede utilizar el siguiente archivo .gitignore

# Dependency directories
node_modules/

# nyc test coverage
.nyc_output

# Coverage directory used by tools like istanbul
coverage

# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov

Conclusiones

Esta entrada finaliza la serie de entradas en las que se ha visto cómo crear una librería JavaScript desde cero. En esta última entrada se ha visto cómo ejecutar múltiples scripts npm para simplificar el proceso. Además, se ha visto un ejemplo de archivo .gitignore para el proyecto.

Todo el código utilizado en esta serie se puede descargar en el siguiente repositorio.

Imágenes: Pixabay (skylarvision)

¿Te ha parecido de utilidad el contenido?

Daniel Rodríguez

Share
Published by
Daniel Rodríguez
Tags: Node

Recent Posts

Champion vs Challenger: Cómo los Bancos Validan Modelos Nuevos antes de Ponerlos en Producción

Has construido un nuevo modelo de credit scoring. Las métricas de validación son mejores que…

1 día ago

Cómo Comparar Dos Hipotecas con Todos los Gastos Incluidos

Comparar dos hipotecas parece sencillo: la que tenga el TIN más bajo es la mejor…

6 días ago

Segmentación RFM: cómo clasificar tu cartera de clientes antes de calcular el CLV

En un artículo anterior vimos la fórmula clásica del CLV junto a sus limitaciones. Una…

1 semana ago

Los récords con asterisco, o la épica del titular sin contexto – El bestiario de los indicadores económicos absurdos (parte 8 y final)

Y llegamos al final de una serie que había programado para ser de tres entradas.…

2 semanas ago

PSI: Cómo Saber Cuándo tu Modelo de Credit Scoring se ha Degradado

Un modelo de credit scoring no es un artefacto estático. Se construye en un momento…

2 semanas ago

Los indicadores que se autocumplen, o cuando medir es modificar – El bestiario de los indicadores económicos absurdos (parte 7)

En las seis entregas anteriores hemos paseado por casi todos los géneros del disparate económico:…

3 semanas ago

This website uses cookies.