En este segundo artículo de la serie sobre las distintas herramientas orientadas a la experiencia de desarrollo revisaremos que es npm.

Puedes encontrar el primer artículo: ¿Qué es Linting y ESLint? en este enlace.

¿Qué es npm?

npm es parte esencial de Node.js, el entorno de ejecución de javaScript en el lado del servidor basado en el motor V8 de Google. Es muy seguramente la principal razón del gran éxito de Node permitiendo que cientos de desarrolladores puedan compartir paquetes de software entre distintos proyectos.

En este momento, se han publicado 1,493,231 paquetes por medio de su repositorio con más de 27 mil millones de descargas.

npm responde a las siglas de Node Package Manager o manejador de paquetes de node, es la herramienta por defecto de JavaScript para la tarea de compartir e instalar paquetes.

Tal como reza su documentación, npm se compone de al menos dos partes principales.

• Un repositorio online para publicar paquetes de software libre para ser utilizados en proyectos Node.js
• Una herramienta para la terminal (command line utility) para interactuar con dicho repositorio que te ayuda a la instalación de utilidades, manejo de dependencias y la publicación de paquetes.

Es decir, en tu proyecto basado en Node — que actualmente incluye los proyectos de aplicaciones web que utilizan Node para su proceso de compilación y generación de archivos — utilizarás la utilidad de linea de comandos (cli) para consumir paquetes desde el repositorio online, un listado gigantesco de soluciones de software para distintos problemas disponibles públicamente en npmjs.com y para manejar dependencias, y para ello necesitas un archivo de configuración que le diga a npm que este es un proyecto node.

package.json

Este archivo indica a npm que el directorio en el que se encuentra es en efecto un proyecto o paquete npm. Este archivo contiene la información del paquete incluyendo la descripción del mismo, versión, autor y más importante aún dependencias.

Este archivo es generado automáticamente mediante la ejecución de un script de npm: npm init este script es ejecutao para inicializar un proyecto JavaScript, al ejecutarlo la linea de comandos te hará algunas preguntas para crear el paquete:

 $ npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help init` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (test)

Esta utilidad te guiará en el proceso de crear un archivo package.json. Solo cubre los items más comunes y trata de adivinar algunos valores por defecto. Revisa npm help init para documentación más a fondo sobre estos campos y que hacen exactamente. Utiliza npm install <pkg> para instalar paquetes y guardarlos como dependencia en el archivo package.json. Presiona ^C en cualquier momento para cancelar

nombre del paquete: (que-es-npm)

Lo primero que verás al ejecutar npm init es un mensaje como el anterior y la primera pregunta: nombre del paquete: (que-es-npm) que entre paréntesis mostrará el nombre del directorio en el que se está ejecutando como nombre por defecto.

Luego veras lo siguiente.

version: (1.0.0)
description:
entry point: (index.js)
test command:
git repository:
author:
license (MIT):
private:

Puedes simplemente presionar Enter en cada una de estas opciones para dejar vació el campo o guardar el valor por defecto que se muestra entre paréntesis.

• version: Corresponde a la versión de tu proyecto. Lo ideal es mantener este campo actualizado cuando modificas algo en tu proyecto o librería utilizando por ejemplo semver.
• description: Una breve descripción de tu proyecto. Particularmente importante si lo que estás creando es un paquete que publicarás vía npm.
• entry point: Define cuál será el punto de "entrada" de tu proyecto. Esto es, que archivo se ejecutará cuando se importe tu proyecto dentro de otro. Nuevamente, especialmente importante para paquetes de librerías.
• test command: Aquí puedes definir el comando que quieres ejecutar para realizar las pruebas de tu proyecto, este comando se ejecutará cuando escribas npm run test en tu terminal.
• git repository: Define la url del repositorio git en donde este proyecto está alojado, se utiliza para informar a los usuarios de tu paquete el repositorio en donde encontrar el código fuente del proyecto.
• author: El nombre e email de quien creó este proyecto.
• license: Identifica el tipo de licencia de uso de tu proyecto. Permite a las personas saber que y que no está permitido al usar tu código. Puedes encontrar la lista completa de licencias soportadas por este campo aquí.
• private: Es un valor boolean que te permite evitar que tu paquete se publique en el repositorio. Si lo que estás creando es un proyecto personal este valor será true.

Una vez contestadas todas las preguntas y terminado el proceso de inicialización tendrás un nuevo archivo dentro del directorio de tu proyecto: project.json cuyo contenido será similar a este

{
  "name": "que-es-npm",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \\"Error: no test specified\\" && exit 1"
  },
  "author": "Matias Hernandez <matiasfh@gmail.com> (<https://matiashernandez.dev>)",
  "license": "ISC"
}

npm scripts

Una importante sección de este archivo es scripts. Esta sección define un listado de propiedades que permiten ejecutar comandos dentro del contexto de tu proyecto incluyendo: comandos de otros paquetes listados como dependencias, scripts personalizados, scripts bash, etc.

Por defecto se crea un script para ejecutar el comando de test que, si no agregaste nada personalizado en el proceso de inicialización sólo tendrá una llamada al comando echo, es decir, ****al ejecutar en la terminal npm run test verás en la consola Error: no test specified

Un ejemplo de producción de esta sección es:

{
		...
		...
    "scripts": {
        "start": "npm run generate && PORT=5000 react-scripts start",
        "build": "react-scripts build",
        "storybook": "start-storybook -p 6006 -h localhost",
        "build-storybook": "build-storybook -s public",
        "test": "jest",
        "test:watch": "jest --watch --silent",
        "cypress": "cypress run",
        "eject": "react-scripts eject",
        "lint": "eslint src/**/*.{js,ts,tsx} --fix",
        "prettier": "npx prettier --write '**/*.tsx'",
        "generate": "graphql-codegen --config codegen.yml"
    },
    ...
		...
}

En este ejemplo podemos ver una lista de 11 scripts que cumplen diferentes tareas tales como:

• start: Primero ejecuta el script generate y luego inicia la aplicación web. react-scripts es una dependencia del paquete y se encuentra disponible dentro del directorio node_modules.
• build: Ejecuta la compilación de la aplicación en modo producción.
• lint: Ejecuta el proceso de linting (revisión de formato y estilo de código) del proyecto (Puedes leer más sobre este proceso en el primer artículo de esta colección)
• test: Ejecuta el script de pruebas basado en el paquete jest que también está instalado como dependencia.
• prettier: Ejecuta prettier mediante el uso de npx. Este es un paquete especial de npm que permite ejecutar binarios dentro del alcance de tu proyecto sin necesidad de especificar dicho comando como script dentro del archivo package.json.

Dependencias y dependencias de desarrollo

La siguiente sección muy relevante dentro del archivo es el listado de dependencias y el listado de dependencias de desarrollo

{
   
    "dependencies": {
        "react": "^17.0.1",
        "react-dom": "^17.0.1",
        "react-hook-form": "6.14.1",
        "react-i18next": "11.8.5",
        "react-query": "^3.5.12",
        "react-router-dom": "5.2.0",
        "react-scripts": "4.0.1",
        "react-table": "^7.6.3",
        "react-virtual": "2.3.2",
        "yup": "0.32.8"
    },
		...
		...
    "devDependencies": {
        "@emotion/jest": "11.1.0",
        "@graphql-codegen/add": "2.0.2",
        "@graphql-codegen/cli": "1.20.1",
        "@graphql-codegen/introspection": "1.18.1",
        "@graphql-codegen/typescript": "1.20.2",
        "@graphql-codegen/typescript-graphql-request": "3.0.1",
        "@graphql-codegen/typescript-operations": "1.17.14",
        "@types/jest": "^26.0.20",
        "@types/node": "^12.0.0",
        "@types/react": "^16.9.53",
        "@types/react-dom": "^16.9.8",
        "@types/react-router-dom": "^5.1.7",
        "cypress": "^6.2.1",
        "eslint": "^7.17.0",
        "eslint-config-prettier": "^7.1.0",
        "eslint-plugin-prettier": "^3.3.1",
        "starwars-names": "1.6.0",
        "stylelint": "13.8.0",
        "stylelint-config-prettier": "8.0.2",
        "stylelint-prettier": "1.1.2",
        "ts-jest": "^26.4.4"
    }
}

Estas secciones, definen que paquetes disponibles en el repositorio de npm son requeridos por tu proyecto indicando también la versión necesaria. La versión mostrada aquí está en formato semver y corresponde al campo versionmencionado antes.

Estas dependencias son instaladas al ejecutar npm install <pkg> --save y en el caso de las dependencias de desarrollo utilizando npm install <pkg> --save-dev.

La diferencia de estos listados es que dependencies está destinado a ser utilizando en producción y devDependenciesdefine paquetes que son necesarios sólo durante el desarrollo de tu proyecto.

Es importante conocer cómo se definen las versiones a utilizar en estas dependencias. Cada una de ellas muestra un número basado en semver en la forma mayor.minor.patch.

• mayor: Representa una versión mayor que genera cambios en la API del producto.
• minor: Representa un valor que aumenta cuando se hacen cambios retro-compatibles.
• patch: Un valor que aumenta cada vez que se hacen reparaciones de errores o mejoras sutiles.

También es posible encontrar algunos símbolos frente a la numeración de la versión, estos son:

• ^: latest minor release. Por ejemplo ^1.0.4 indica que 1.0.4 es la versión más "baja" que se puede instalar pero permite que se instale cualquier versión superior a esa pero que se encuentre dentro de la versión 1.
• ~: latest patch release. Esta es la forma contraria a  ^. Esta especificación  ~1.0.4 puede instalar la versión 1.0.7 si es que esta es la ultima version del patch.

Una vez instalados los paquetes de tus dependencias la información de las versiones instaladas queda almacenada en un archivo llamado package-lock.json

package-lock.json

Este archivo es auto generado por npm install y es una lista descriptiva y exacta de las versiones instaladas durante tu proceso. No esta destinado a ser leído ni manipulado por los desarrolladores, si no, para ser un insumo del proceso de manejo de dependencias.

¿Cómo trabajar con npm?

Lo más usual que harás con npm es la instalación de dependencias, esto se hace mediante npm install para instalar todas las dependencias listadas en el archivo package.json o utilizando npm install <pkg> para instalar algún paquete en particular.

npm install

Este script nativo de npm tiene algunas otras opciones a la hora de hacer la instalación de paquetes.

Por defecto al ejecutar npm install <pkg> la última versión disponible en el repositorio agregando el símbolo ^ a la versión.

Al ejecutar npm install <pkg> el paquete se instalará dentro del directorio node_modules que está dentro de tu proyecto.

Puedes usar algunos parámetros tales como

• -g para indicar que quieres que el paquete se instale globalmente
• --production indica que la ejecución de npm install solo instalará las dependencias listadas en el apartado dependencies dejando de lado las dependencias de desarrollo.

npm audit

npm tiene una miriada de paquetes disponibles lo que es una gran característica indicando lo saludable del ecosistema que es capaz de generar nuevas librerías a gran velocidad, pero también puede ser un problema. npm puede albergar paquetes maliciosos o con problema de seguridad.

La organización trás npm mantiene una lista de agujeros de seguridad y puedes utilizar este comando para revisar tus dependencias.

npm audit te entregará información de las vulnerabilidades encontradas en tus dependencias junto con una breve descripción de como resolverlo indicando la versión que corrige el defecto.

npm publish

En el caso de que tu proyecto sea una librería de software libre que quieres compartir con otros, este comando será el que te permitirá publicar tu paquete en el repositorio, solo necesitas ejecutar:

• npm login para ingresar a tu cuenta de npm
• npm publish para subir tu paquete al repositorio

Ten en cuenta que necesitas tener bien configurados tu entry point y el script de build.

También puedes hacer uso de los scripts del ciclo de vida. Una serie de scripts que se ejecutan en diferentes momentos del proceso de publicación:

• prepare (desde npm@4.0.0): Se ejecuta antes de que el paquete se empaquete (packed) y antes de que se publique. También se ejecuta al correr npm install y después del script prepublishOnly
• prepublishOnly: Se ejecuta antes de que el paquete sea preparado y empaquetado y solo cuando se ejecuta npm publish
• prepack: Se ejecuta antes de empaquetar, es decir antes de npm pack y npm publish
• postpack: Se ejecuta después de que el paquete fuese generado y ubicado en su destino final.

¿Cuándo usar estos scripts?

Cuando necesitas que tu paquete ejecuta alguna acción antes de ser utilizado y que no dependa del sistema operativo en que está siendo instalado, por ejemplo: transpilar tu código Typescript a JavaScript, obtener datos remotos que tu paquete necesita, etc.

¿Qué scripts se ejecutan al publicar un paquete?

Cuando ejecutas npm publish una serie de scripts son ejecutados automáticamente por npm el orden de estos scripts es el siguiente:

• prepublishOnly
• prepare
• prepublish
• publish
• postpublish

Es decir, si necesitas ejecutar algún comando antes de que se publique tu paquete debes configurar el script prepublishOnly ¿Cómo?

{
	"scripts": {
		"prepublishOnly": "compile-my-code src/"
	}
}

Conclusión

npm es la solución que ofrece el ecosistema de JavaScript para manejar dependencias, auditar paquetes y mantener un repositorio de paquetes disponible para todos los usuarios, es la herramienta central de todo proyecto JavaScript sea este backend o frontend.

El sistema de npm se basa en un archivo centralizado que describe los metadatos del proyecto, scripts y dependencias tanto de producción como de desarrollo.

npm (node package manager) es el gestor de dependencias/paquetes que obtienes por defecto cuando instalas Node.js. Proporciona una manera para que los desarrolladores instalen paquetes tanto a nivel global como local.

A veces puede que quieras echar un vistazo a un paquete específico y probar algunos comandos. Pero no puedes hacerlo sin instalar las dependencias en tu carpeta local de node_modules.

Ahí es donde entra npx.

En este artículo, vamos a echar un vistazo a las diferencias entre npm y npx y aprenderemos cómo obtener lo mejor de ambos.

En primer lugar, vamos a entender lo que npm es en realidad y lo que podemos hacer con él.

El gestor de paquetes npm

npm es un par de cosas. En primer lugar, es un repositorio en línea para la publicación de proyectos de código abierto Node.js.

Segundo, es una herramienta CLI que ayuda a instalar esos paquetes y a manejar sus versiones y dependencias. Hay cientos de miles de librerías y aplicaciones de Node.js en npm y muchas más se agregan cada día.

npm por sí mismo no tiene ningún paquete. Si quieres ejecutar un paquete usando npm, debes especificar ese paquete en tu archivo package.json.

Cuando los ejecutables se instalan a través de paquetes npm, npm crea enlaces a ellos:

• las instalaciones locales tienen enlaces creados en el directorio ./node_modules/.bin/
• las instalaciones globales tienen enlaces creados desde el directorio global bin/ (por ejemplo: /usr/local/bin en Linux o %AppData%/npm en Windows)

Para ejecutar un paquete con npm tienes que escribir la ruta local, así:

$ ./node_modules/.bin/tu-paquete

o puedes ejecutar un paquete instalado localmente agregándolo a tu archivo package.json en la sección de scripts, así:

{
  "name": "tu-aplicacion",
  "version": "1.0.0",
  "scripts": {
    "tu-paquete": "tu-paquete"
  }
}

Luego puedes ejecutar el script usando npm run:

npm run tu-paquete

Puedes ver que manejar un paquete con npm simple requiere bastante ceremonia.

Afortunadamente, aquí es donde npx es útil.

El ejecutor de paquetes npx

Desde la versión 5.2.0 de npm, npx está preinstalado con npm. Así que es más o menos estándar hoy en día.

npx es también una herramienta CLI cuyo propósito es facilitar la instalación y la gestión de las dependencias alojadas en el registro npm.

Ahora es muy fácil ejecutar cualquier tipo de ejecutable basado en Node.js que normalmente se instalaría a través de npm.

Puedes ejecutar el siguiente comando para ver si ya está instalado para tu versión actual de npm:

$ which npx

Si no lo está, puede instalarlo así:

$ npm install -g npx

Una vez que te asegures de tenerlo instalado, veamos algunos de los casos de uso que hacen que npx sea extremadamente útil.

Ejecutar un paquete instalado localmente fácilmente

Si deseas ejecutar un paquete instalado localmente, todo lo que tienes que hacer es escribir:

$ npx tu-paquete

npx comprobará si <comando> o <paquete> existe en $PATH, o en los binarios del proyecto local, y si es así lo ejecutará.

Ejecutar los paquetes que no estén previamente instalados

Otra gran ventaja es la capacidad de ejecutar un paquete que no fue instalado previamente.

A veces sólo quieres usar algunas herramientas CLI pero no quieres instalarlas globalmente sólo para probarlas. Esto significa que puedes ahorrar algo de espacio en disco y simplemente ejecutarlos sólo cuando los necesites. Esto también significa que tus variables globales estarán menos contaminadas.

Ejecuta código directamente desde GitHub

Este es bastante radical.

Puedes usar npx para ejecutar cualquier gist y repositorio de GitHub. Centrémonos en ejecutar un gist de GitHub porque es más fácil crear uno.

El script más básico consiste en el archivo principal de JS y un package.json. Después de configurar los archivos, todo lo que tienes que hacer es ejecutar el npx con el enlace a ese gist como se muestra en la imagen de arriba.

Aquí puedes encontrar el código que usé para este ejemplo.

Asegúrate de leer atentamente cualquier script antes de ejecutarlo para evitar problemas serios que pueden ocurrir debido a código malicioso.

Prueba diferentes versiones de los paquetes

npx hace que sea extremadamente fácil probar diferentes versiones de un paquete o módulo de Node.js. Para probar esta impresionante característica, vamos a instalar localmente el paquete create-react-app y probar una próxima versión.

Esto enlistará algunas etiquetas dist cerca del final de la salida. Las etiquetas dist proporcionan alias para los números de versión, lo que hace que sea mucho más fácil de escribir.

$ npm v create-react-app

Usemos npx para probar la etiqueta dist next de create-react-app que creará la aplicación dentro de un directorio sandbox.

$ npx create-react-app@next sandbox

npx instalará temporalmente la siguiente versión de create-react-app, y luego se ejecutará para andamiar la aplicación e instalar sus dependencias.

Una vez instalada, podemos navegar a la aplicación de esta manera:

$ cd sandbox

y luego empezar con este comando:

$ npm start

Se abrirá automáticamente la aplicación de React en una ventana de tu navegador predeterminado. ¡Ahora tenemos una aplicación que funciona en la próxima version del paquete create-react-app!

Conclusión

npx nos ayuda a evitar el versionado, los problemas de dependencia y la instalación de paquetes innecesarios que sólo queremos probar.

También proporciona una forma clara y fácil de ejecutar paquetes, comandos, módulos e incluso listas y repositorio de GitHub.

Si no has usado npx antes, ¡ahora es un buen momento para empezar!

Esto fue originalmente publicado en mi blog.
Puedes contactarme y preguntarme cualquier cosa en Twitter y Facebook.

Traducido del artículo de Carol-Theodor Pelu - npm vs npx — What’s the Difference?

Node.js ha estado tomando el mundo por asalto desde 2009. Cientos de miles de sistemas han sido construidos usando Node.js, lo que ha llevado a la comunidad de desarrolladores a afirmar que "JavaScript se está comiendo el software".

Uno de los principales factores del éxito de Node es npm - su popular gestor de paquetes, que permite a los desarrolladores de JavaScript compartir paquetes útiles como lodash y moment de forma rápida y fácil.

En el momento en que estoy escribiendo este post, ¡npm ha facilitado la publicación de más de 1.3 millones de paquetes con una tasa de descarga semanal de más de 16 mil millones! Estos números son fantásticos para cualquier herramienta de software. Así que ahora hablemos de lo que es npm exactamente.

¿Qué es NPM?

NPM – o "Node Package Manager" – es el administrador de paquetes predeterminado para el tiempo de ejecución de JavaScript Node.js.

También se conoce como "Ninja Pumpkin Mutants", "Nonprofit Pizza Makers", y una serie de otros nombres al azar que puedes explorar y probablemente puedas contribuir en npm-expansions.

NPM consiste de dos partes principales:

• una herramienta CLI (interfaz de línea de comandos) para la publicación y descarga de paquetes, y
• un repositorio en línea que alberga paquetes de JavaScript

Para una explicación más visual, podemos pensar en el repositorio npmjs.com como un centro de cumplimiento que recibe paquetes de bienes de los vendedores (autores de paquetes npm) y los distribuye a los compradores (usuarios de paquetes npm).

Para facilitar este proceso, el centro de cumplimiento npmjs.com emplea un ejército de trabajadores wombats (npm CLI) que serán asignados como asistentes personales a cada cliente individual de npmjs.com. Así que las dependencias se entregan a los desarrolladores de JavaScript de esta manera:

y el proceso de publicar un paquete para tus compañeros de JS sería algo así:

Veamos cómo este ejército de wombats ayuda a los desarrolladores que quieren usar paquetes de JavaScript en sus proyectos. También veremos cómo ayudan a los magos del código abierto a sacar sus geniales librerías al mundo.

package.json

Cada proyecto en JavaScript – ya sea Node.js o una aplicación de navegador – puede ser enfocado como un paquete npm con su propia información de paquete y su archivo package.json para describir el proyecto.

Podemos pensar en package.json como etiquetas estampadas en esas buenas cajas de npm que nuestro ejército de Wombats entrega.

package.json se generará cuando se ejecute npm init para inicializar un proyecto JavaScript/Node.js, con estos metadatos básicos proporcionados por los desarrolladores:

• name: el nombre de tu librería/proyecto JavaScript
• version: la versión de tu proyecto. A menudo, para el desarrollo de aplicaciones, este campo es a menudo descuidado ya que no hay necesidad aparente de versionar librerías de código abierto. Pero aún así, puede ser útil como fuente de la versión del despliegue
• description: la descripción del proyecto
• license: la licencia del proyecto

npm scripts

package.json también soporta la propiedad scripts que puede definirse para ejecutar herramientas de línea de comandos que se instalan en el contexto local del proyecto. Por ejemplo, la porción de scripts de un proyecto npm puede tener un aspecto similar a este:

{
  "scripts": {
    "build": "tsc",
    "format": "prettier --write **/*.ts",
    "format-check": "prettier --check **/*.ts",
    "lint": "eslint src/**/*.ts",
    "pack": "ncc build",
    "test": "jest",
    "all": "npm run build && npm run format && npm run lint && npm run pack && npm test"
  }
}

con eslint, prettier, ncc, jest no necesariamente instalados como ejecutables globales sino como locales de tu proyecto dentro de node_modules/.bin/.

La reciente introducción de npx nos permite ejecutar estos comandos node_modules del proyecto al igual que un programa instalado globalmente usando el prefijo npx ... (es decir, `npx prettier --write **/*.ts).

dependencies vs devDependencies

Estos dos vienen en forma de objetos clave-valor (key-value) con los nombre de las librerías npm como clave y sus versiones en formato semántico como valor. Este es un ejemplo de la plantilla de Github's TypeScript Action:

{
  "dependencies": {
    "@actions/core": "^1.2.3",
    "@actions/github": "^2.1.1"
  },
  "devDependencies": {
    "@types/jest": "^25.1.4",
    "@types/node": "^13.9.0",
    "@typescript-eslint/parser": "^2.22.0",
    "@zeit/ncc": "^0.21.1",
    "eslint": "^6.8.0",
    "eslint-plugin-github": "^3.4.1",
    "eslint-plugin-jest": "^23.8.2",
    "jest": "^25.1.0",
    "jest-circus": "^25.1.0",
    "js-yaml": "^3.13.1",
    "prettier": "^1.19.1",
    "ts-jest": "^25.2.1",
    "typescript": "^3.8.3"
  }
}

Estas dependencias se instalan mediante el comando npm install con las banderas --save y --save-dev. Están pensadas para ser usadas en entornos de producción y desarrollo/prueba respectivamente. Profundizaremos en la instalación de estos paquetes en la siguiente sección.

Mientras tanto, es importante entender los posibles signos que vienen antes de las versiones semánticas (suponiendo que hayas leído el modelo major.minor.patch (mayor.menor.parche) de semver):

• ^: último lanzamiento menor. Por ejemplo, una especificación ^1.0.4 podría instalar la versión 1.3.0 si es la última versión menor de la serie mayor 1.
• ~: última versión del parche. De la misma manera que ^ para las versiones menores, la especificación ~1.0.4 podría instalar la versión 1.0.7 si es la última versión menor de la serie menor 1.0.

Todas estas versiones exactas del paquete se documentarán un archivo generado package-lock.json.

package-lock.json

Este archivo describe las versiones exactas de las dependencias utilizadas en un proyecto de JavaScript npm. Si package.json es una etiqueta descriptiva genérica, package-lock.kson es una tabla de ingredientes.

Y al igual que no solemos leer la tabla de ingredientes de un producto (a menos que estés demasiado aburrido o necesites saberlo), package-lock.json no está pensado para ser leído línea por línea por los desarrolladores (a menos que estemos desesperados por resolver problemas de "funciona en mi máquina").

package-lock.json es usualmente generado por el comando npm install, y también es leído por nuestra herramienta NPM CLI para asegurar la reproducción de los entornos de construcción para el proyecto con npm ci.

Cómo ordenar efectivamente a NPM Wombats como un "comprador"

Como se deduce de los 1.3 millones de paquetes publicados frente a los 16,000 millones de descargas mencionadas anteriormente, la mayoría de los usuarios de npm utilizan npm en esta dirección. Así que es bueno saber cómo manejar esta poderosa herramienta.

npm install

Este es el comando más utilizado en el desarrollo de aplicaciones JavaScript/Node.js hoy en día.

Por defecto, npm install <nombre del paquete> instalará la última versión con el signo ^. Un npm install dentro del contexto de un proyecto npm descargará los paquetes en la carpeta node_modules del proyecto según las especificaciones de package.json, actualizando la versión del paquete (y a su vez regenerando package-lock.json) donde pueda basándose en la coincidencia de las versiones ^ y ~.

Puedes especificar una bandera global -g si deseas instalar un paquete en el contexto global que puedes utilizar en cualquier lugar de tu máquina (esto es común para los paquetes de herramientas de línea de comandos como live-server).

npm ha hecho la instalación de los paquetes de JavaScript tan fácil que este comando se utiliza a menudo de forma incorrecta. Esto resulta en que npm es el blanco de muchas bromas de programadores como estas:

¡Aquí es donde la bandera --production viene al rescate! En la sección anterior, discutimos las dependencies y devDependencies destinadas a ser usadas en entornos de producción y desarrollo/prueba respectivamente. Esta bandera de --production es la forma en que se hacen las diferencias en node_modules.

Al adjuntar esta bandera al comando npm install, sólo instalaremos paquetes de dependencies, reduciendo así drásticamente el tamaño de nuestros node_modules a lo que sea absolutamente necesario para que nuestras aplicaciones estén en funcionamiento.

Al igual que cuando los niños y niñas exploradoras no trajeron exprimidores de limón a nuestra cabina de limonada, ¡No deberíamos llevar las devDependencies a producción!

npm ci

Así que si npm install --production es óptimo para un entorno de producción, ¿Debe haber un comando que sea óptimo para mi desarrollo local, probando la configuración?

La respuesta es npm ci.

Al igual que si package-lock.json no existe ya en el proyecto que se genera cada vez que se llama npm install, npm ci consume este archivo para descargar la versión exacta de cada paquete individual del que depende el proyecto.

Así es como podemos asegurarnos de que el contexto de nuestro proyecto se mantiene exactamente igual en las diferentes máquina, ya sean nuestras laptops utilizados para el desarrollo o CI (Integración Continua) como GitHub Actions.

npm audit

Con el enorme número de paquetes que se han publicado y que pueden ser fácilmente instalados, los paquetes npm son susceptibles a los malos autores con intenciones maliciosas.

Al darse cuenta de que había un problema en el ecosistema, la organización npm.js tuvo la idea de npm audit. Mantienen una lista de lagunas de seguridad para que los desarrolladores puedan auditar sus dependencias con el uso del comando npm audit.

npm audit da a los desarrolladores información sobre las vulnerabilidades y si hay versiones con correcciones a las que actualizar. Por ejemplo,

Si las correcciones están disponibles en las próximas actualizaciones de versiones que no sean de última hora, se puede utilizar npm audit para actualizar automáticamente las versiones de las dependencias afectadas.

Cómo ordenar efectivamente a NPM Wombats como un "vendedor"

Hemos repasado cómo manejar la herramienta NPM CLI como consumidor, pero ¿Qué tal si la usamos efectivamente como autor (y potencialmente nos convertimos en un mago del código abierto de JavaScript)?

npm publish

Enviar un paquete a nuestro centro de cumplimiento de npmjs.com es súper fácil ya que sólo tenemos que ejecutar npm publish. La parte difícil, que no es específica de los autores de los paquetes de npm, es determinar la versión del paquete.

La regla empírica según semver.org:

1. Versión MAYOR cuando haces cambios incompatibles en la API,
2. Versión MENOR cuando se agrega la funcionalidad de una manera compatible con el pasado, y
3. Versión PARCHE cuando haces correcciones de errores compatibles con el pasado.

Es aún más importante seguir la regla anterior cuando publiques tus paquetes para asegurarte de que no estás rompiendo el código de nadie ya que la versión por defecto que coincide en npm es ^ (también conocida como la siguiente versión menor).

❤️ npm ❤️ JavaScript ❤️ Node.js ❤️

¡Eso es todo lo que necesitamos saber para empezar a manejar npm efectivamente y ordenar nuestro encantador ejército de wombats!

Traducido del artículo de Stanley Nguyen - What is npm? A Node Package Manager Tutorial for Beginners