NPM vs PNPM vs Yarn - JavaScript Package Managers

As JavaScript developers, we have access to several package managers. In this guide, we compare the most popular ones: npm, yarn, and pnpm.

In modern application development, we don’t write everything from scratch. Instead, we prefer to use existing open-source packages. Each of these packages has its own maintainers and community. So, using a package in our projects gives us some advantages like faster development, access to new, regular updates, and better security than custom-created script.

It’s common that one package depends on many other packages to work correctly. Similarly, the other packages may also depend on something like lodash, but lodash itself depends on several packages as well. In other words, the nested dependencies can sometimes become so complex that they are unable to handle dependency management manually.

Here’s when a package manager is extremely useful. Package managers are tools that automatically handle the dependencies of a project.

For example, a package manager can install new — or update existing — packages with a single command. Because everything is automated, so there’s no chance for human error. As JavaScript developers, we have access to several package managers. But, in this guide, we’ll compare the three most popular ones:

• npm
• Yarn
• pnpm

#javascript #npm #node #yarn #developer

What is GEEK

Buddha Community

NPM vs PNPM vs Yarn - JavaScript Package Managers

As JavaScript developers, we have access to several package managers. In this guide, we compare the most popular ones: npm, yarn, and pnpm.

In modern application development, we don’t write everything from scratch. Instead, we prefer to use existing open-source packages. Each of these packages has its own maintainers and community. So, using a package in our projects gives us some advantages like faster development, access to new, regular updates, and better security than custom-created script.

It’s common that one package depends on many other packages to work correctly. Similarly, the other packages may also depend on something like lodash, but lodash itself depends on several packages as well. In other words, the nested dependencies can sometimes become so complex that they are unable to handle dependency management manually.

Here’s when a package manager is extremely useful. Package managers are tools that automatically handle the dependencies of a project.

For example, a package manager can install new — or update existing — packages with a single command. Because everything is automated, so there’s no chance for human error. As JavaScript developers, we have access to several package managers. But, in this guide, we’ll compare the three most popular ones:

• npm
• Yarn
• pnpm

#javascript #npm #node #yarn #developer

Administradores De Paquetes De JavaScript Comparados: Npm, Yarn O Pnpm

Nota del editor : esta publicación se reescribió por completo el 16 de febrero de 2022 para reevaluar el panorama del administrador de paquetes, hacer referencia y comparar nuevas herramientas y espacios de trabajo, analizar la funcionalidad de Corepack y los impactos en el rendimiento, brindar una vista panorámica del uso del administrador de paquetes entre proyectos populares de código abierto y explicar más a fondo la evolución de los gestores de paquetes desde 2010.

Actualmente existen tres jugadores principales en el campo de los administradores de paquetes:

1. sobre el nivel del mar
2. Yarn : veremos en breve que Yarn puede referirse a Yarn Classic (< v2) o a su versión más moderna Yarn Berry (≥ v2)
3. rendimiento sobre el nivel del mar (pnpm)

Prácticamente, hemos logrado la paridad de características entre todos los administradores de paquetes, por lo que lo más probable es que decida qué administrador de paquetes usar en función de los requisitos no funcionales, como la velocidad de instalación, el consumo de almacenamiento o cómo se integra con su flujo de trabajo existente.

Por supuesto, la forma en que elija usar cada administrador de paquetes será diferente, pero todos comparten un conjunto de conceptos principales. Puede hacer lo siguiente con cualquiera de estos administradores de paquetes:

• Manejar y escribir metadatos
• Instalar por lotes o actualizar todas las dependencias
• Agregar, actualizar y eliminar dependencias
• Ejecutar guiones
• Publicar paquetes
• Realizar auditorías de seguridad

Sin embargo, a pesar de esta paridad, los administradores de paquetes difieren bajo el capó. Tradicionalmente, npm e Yarn han instalado dependencias en una node_modulescarpeta plana . Pero esta estrategia de resolución de la dependencia no está exenta de críticas.

Por lo tanto, pnpm ha introducido algunos conceptos nuevos para almacenar dependencias de manera más eficiente en una node_modulescarpeta anidada. Yarn Berry va aún más lejos al abandonar por node_modulescompleto su modo Plug'n'Play (PnP).

Siéntase libre de saltar y leer lo que sea más relevante para usted.

Cómo utilizar el proyecto complementario

Creé una aplicación React complementaria para demostrar algunos de los conceptos únicos de los diferentes administradores de paquetes. Existe una rama Git correspondiente para cada variante del administrador de paquetes. Este es el proyecto que también utilicé para crear la tabla de rendimiento en la sección a continuación de esta publicación.

Aunque el tipo de aplicación no es importante para el tema de este artículo, he elegido un proyecto de tamaño mediano y realista para poder iluminar diferentes aspectos; como ejemplo del pasado reciente, el mecanismo PnP de Yarn Berry provocó algunas discusiones acaloradas sobre problemas de compatibilidad que este proyecto es adecuado para ayudar a examinar.

Una breve historia de los administradores de paquetes de JavaScript

El primer administrador de paquetes que se lanzó fue npm, en enero de 2010. Estableció los principios básicos de cómo funcionan los administradores de paquetes en la actualidad.

Si npm existe desde hace más de 10 años, ¿por qué existen alternativas? Aquí hay algunas razones clave por las que han surgido:

• Diferentes algoritmos de resolución de dependencias con diferentes node_modulesestructuras de carpetas (anidado, plano, node_modulesmodo PnP)
• Diferentes soportes para izar , lo que tiene implicaciones de seguridad.
• Diferentes formatos de archivo de bloqueo, cada uno de los cuales tiene implicaciones de rendimiento
• Diferentes enfoques para almacenar paquetes en disco, lo que tiene implicaciones en la eficiencia del espacio en disco
• Soporte diferente para proyectos de paquetes múltiples (también conocidos como espacios de trabajo), lo que afecta la capacidad de mantenimiento y la velocidad de grandes monorepos
• Diferentes necesidades de nuevas herramientas y comandos, cada uno de los cuales tiene implicaciones DX
  • Relacionado, diferentes necesidades de extensibilidad a través de complementos y herramientas comunitarias
• Diferentes grados de configurabilidad y flexibilidad.

Profundicemos en una breve historia de cómo se identificaron estas necesidades después de que npm saltó a la fama, cómo Yarn Classic resolvió algunas de ellas, cómo pnpm amplió estos conceptos y cómo Yarn Berry, como sucesor de Yarn Classic, trató de romper el molde. por estos conceptos y procesos tradicionales.

sobre el nivel del mar, el pionero

npm es el antepasado de los administradores de paquetes. Por error, mucha gente cree que npm es un acrónimo de “Node package manager”, pero no es así . Sin embargo, se incluye con el tiempo de ejecución de Node.js.

Su lanzamiento supuso una revolución porque, hasta entonces, las dependencias de los proyectos se descargaban y gestionaban de forma manual. Conceptos como el package.jsonarchivo con sus campos de metadatos (p. ej., devDependencies), el almacenamiento de dependencias en node_modules, scripts personalizados, registros de paquetes públicos y privados, y más, fueron introducidos por npm.

En 2020, GitHub adquirió npm , por lo que, en principio, npm ahora está bajo la administración de Microsoft. Al momento de escribir este artículo, la versión principal más reciente es v8 , lanzada en octubre de 2021.

Yarn (v1 / Classic), responsable de muchas innovaciones

En una publicación de blog de octubre de 2016 , Facebook anunció un esfuerzo de colaboración con Google y algunos otros para desarrollar un nuevo administrador de paquetes que resolvería los problemas de consistencia, seguridad y rendimiento que npm tenía en ese momento. Llamaron a la alternativa Yarn , que significa Otro Negociador de Recursos.

Aunque basaron el diseño arquitectónico de Yarn en muchos conceptos y procesos establecidos por npm, Yarn tuvo un gran impacto en el panorama del administrador de paquetes en su versión inicial. A diferencia de npm, Yarn paralelizó las operaciones para acelerar el proceso de instalación, que había sido un gran problema para las primeras versiones de npm.

Yarn puso el listón más alto en DX, seguridad y rendimiento, y también inventó muchos conceptos, entre ellos:

• Soporte monorepo nativo
• Instalaciones con reconocimiento de caché
• Almacenamiento en caché sin conexión
• Bloquear archivos

Yarn v1 entró en modo de mantenimiento en 2020 . Desde entonces, la línea v1.x se ha considerado heredada y se le cambió el nombre a Yarn Classic. Su sucesor, Yarn v2 o Berry, es ahora la rama de desarrollo activa.

pnpm, rápido y eficiente en disco

La versión 1 de pnpm fue lanzada en 2017 por Zoltan Kochan. Es un reemplazo directo para npm, por lo que si tiene un proyecto npm, ¡puede usar pnpm de inmediato!

El principal problema que tenían los creadores de pnpm con npm e Yarn era el almacenamiento redundante de dependencias que se usaban en todos los proyectos. Aunque Yarn Classic tenía ventajas de velocidad sobre npm, usaba el mismo enfoque de resolución de dependencias, lo cual era imposible para los creadores de pnpm: npm y Yarn Classic usaban elevación para aplanar su node_modules.

En lugar de izar, pnpm introdujo una estrategia alternativa de resolución de dependencias: almacenamiento direccionable por contenido . Este método da como resultado una node_modulescarpeta anidada que almacena paquetes en un almacén global en su carpeta de inicio ( ~/.pnpm-store/). Cada versión de una dependencia se almacena físicamente en esa carpeta solo una vez, lo que constituye una única fuente de verdad y ahorra bastante espacio en disco.

Esto se logra a través de un node_modulesdiseño, utilizando enlaces simbólicos para crear una estructura anidada de dependencias, donde cada archivo de cada paquete dentro de la carpeta es un enlace fijo a la tienda. El siguiente diagrama de la documentación oficial aclara esto.

Fuente: pnpm

La influencia de pnpm se puede ver en su informe de 2021 : los competidores quieren adoptar los conceptos de instalación de pnpm, como la estructura de enlaces simbólicosnode_modules y la gestión eficiente del disco de los paquetes debido a sus innovaciones en el almacenamiento direccionable por contenido .

Yarn (v2, Berry), reinventa la rueda con Plug'n'Play

Yarn 2 se lanzó en enero de 2020 y se anunció como una actualización importante del Yarn original. El equipo de Yarn comenzó a referirse a él como Yarn Berry para que fuera más obvio que era esencialmente un nuevo administrador de paquetes con una nueva base de código y nuevos principios.

La principal innovación de Yarn Berry es su enfoque Plug'n'Play (PnP) , que surgió como una estrategia para corregirnode_modules . En lugar de generar node_modules, se genera un .pnp.cjsarchivo con tablas de búsqueda de dependencias, que se puede procesar de manera más eficiente porque es un archivo único en lugar de una estructura de carpetas anidadas. Además, cada paquete se almacena como un archivo zip dentro de la .yarn/cache/carpeta, lo que ocupa menos espacio en disco que la node_modulescarpeta.

Todo este cambio, y tan rápido, generó una gran controversia después del lanzamiento. Los cambios importantes de PnP requirieron que los mantenedores actualizaran sus paquetes existentes para ser compatibles con él. El nuevo enfoque PnP se usó de forma predeterminada, y volver al node_modulesprincipio no fue sencillo, lo que llevó a muchos desarrolladores destacados a criticar abiertamente a Yarn 2 por no habilitarlo.

Desde entonces, el equipo de Yarn Berry ha abordado muchos problemas en sus versiones posteriores. Para abordar la incompatibilidad de PnP, el equipo ofreció algunas formas de cambiar fácilmente el modo de operación predeterminado. Con la ayuda de un node_modulescomplemento , solo se necesitaba una línea de configuración para usar el node_modulesenfoque tradicional.

Además, el ecosistema de JavaScript ha brindado más y más soporte para PnP a lo largo del tiempo, como puede ver en esta tabla de compatibilidad , y algunos grandes proyectos se han movido para adoptar Yarn Berry. En mi proyecto complementario , también pude implementar correctamente PnP con mi proyecto de demostración React.

Aunque Yarn Berry es bastante joven, también tiene un impacto en el panorama de los administradores de paquetes: pnpm adoptó un enfoque PnP a fines de 2020.

Flujos de trabajo de instalación

Primero se debe instalar un administrador de paquetes en los sistemas locales y de CI/CD de cada desarrollador.

sobre el nivel del mar

npm se envía con Node.js, por lo que no se necesita ningún paso adicional. Además de descargar el instalador de Node.js para su sistema operativo, se ha vuelto una práctica común usar herramientas CLI para administrar versiones de software. En el contexto de Node, Node Version Manager (nvm) o Volta se han convertido en utilidades muy útiles.

Yarn Classic y Yarn Berry

Puede instalar Yarn 1 de diferentes maneras, por ejemplo, como un paquete npm con $ npm i -g yarn.

Para migrar de Yarn Classic a Yarn Berry , la forma recomendada es:

• Instale o actualice Yarn Classic a la última versión 1.x
• Use el yarn set versioncomando para actualizar a la última versión moderna:$ yarn set version berry

Sin embargo, la forma recomendada de instalar Yarn Berry es a través de Corepack.

Corepack fue creado por la gente de Yarn Berry. La iniciativa se llamó originalmente administrador de paquetes (pmm) 🤯 y se fusionó con Node en LTS v16.

Con la ayuda de Corepack, no tiene que instalar los administradores de paquetes alternativos de npm "por separado" porque Node incluye binarios Yarn Classic, Yarn Berry y pnpm como correcciones. Estas correcciones permiten a los usuarios ejecutar comandos Yarn y pnpm sin tener que instalarlos explícitamente primero y sin saturar la distribución de Node.

Corepack viene preinstalado con Node.js ≥ v16.9.0. Sin embargo, para versiones anteriores de Node, puede instalarlo usando $ npm install -g corepack.

Habilite Corepack primero, antes de usarlo. El ejemplo muestra cómo activarlo en Yarn Berry v3.1.1.

# you need to opt-in first
$ corepack enable
# shim installed but concrete version needs to activated
$ corepack prepare yarn@3.1.1 --activate

pnpm

Puede instalar pnpm como un paquete npm con $ npm i -g pnpm. También puede instalar pnpm con Corepack : $ corepack prepare pnpm@6.24.2 --activate.

Estructuras de proyecto

En esta sección verás de un vistazo las principales características de los diferentes gestores de paquetes. Puede detectar fácilmente qué archivos están involucrados en la configuración de administradores de paquetes particulares y qué archivos se generan en un paso de instalación.

Todos los administradores de paquetes almacenan toda la metainformación importante en el archivo de manifiesto del proyecto, package.json. Además, se puede usar un archivo de configuración en el nivel raíz para configurar registros privados o métodos de resolución de dependencias.

Con un paso de instalación, las dependencias se almacenan en una estructura de archivos (por ejemplo, dentro de node_modules) y se genera un archivo de bloqueo. Esta sección no tiene en cuenta la configuración de espacios de trabajo , por lo que todos los ejemplos solo muestran una única ubicación donde se almacenan las dependencias.

sobre el nivel del mar

Con $ npm install, o el más corto $ npm i, se generan un package-lock.jsonarchivo y una carpeta. Se puede colocar un archivo de configuraciónnode_modules opcional en el nivel raíz. Consulte la siguiente sección para obtener más información sobre los archivos de bloqueo..npmrc

.
├── node_modules/
├── .npmrc
├── package-lock.json
└── package.json

Hilo clásico

Ejecutar $ yarncrea un yarn.lockarchivo y una node_modulescarpeta. Un .yarnrcarchivo también puede ser una opción de configuración; Yarn Classic también hace honor a los .npmrcarchivos. Opcionalmente, se puede usar una carpeta de caché ( .yarn/cache/) y una ubicación que almacene la versión actual de Yarn Classic ( .yarn/releases/). Las diferentes formas de configurar esto se pueden ver en la sección de comparación de configuraciones.

.
├── .yarn/
│   ├── cache/
│   └── releases/
│       └── yarn-1.22.17.cjs
├── node_modules/
├── .yarnrc
├── package.json
└── yarn.lock

Baya de hilo connode_modules

Independientemente del modo de instalación, tendrá que manejar más archivos y carpetas en los proyectos de Yarn Berry que en los proyectos que usan otros administradores de paquetes. Algunos son opcionales y otros son obligatorios.

Yarn Berry ya no honra .npmrcni .yarnrcarchiva; en su lugar, se requiere un .yarnrc.ymlarchivo de configuración . Para un flujo de trabajo tradicional con una node_modulescarpeta generada, debe proporcionar una nodeLinkerconfiguración que use una node_modulesvariante de instalación inspirada en pnpm.

# .yarnrc.yml
nodeLinker: node-modules # or pnpm

La ejecución $ yarninstala todas las dependencias en una node_modulescarpeta. Se yarn.lockgenera un archivo más nuevo pero incompatible con Yarn Classic. Además, .yarn/cache/se genera una carpeta que se usa para instalaciones sin conexión. La releasescarpeta es opcional y almacena la versión de Yarn Berry que usa el proyecto, como veremos en la sección de comparación de configuraciones.

.
├── .yarn/
│   ├── cache/
│   └── releases/
│       └── yarn-3.1.1.cjs
├── node_modules/
├── .yarnrc.yml
├── package.json
└── yarn.lock

Baya de hilo con PnP

Tanto para los modos PnP estrictos como flexibles$ yarn , la ejecución genera .yarn/cache/y .yarn/unplugged/, junto con .pnp.cjsy yarn.lockarchivos. PnP estricto es el modo predeterminado, pero para suelto, se requiere una configuración.

# .yarnrc.yml
nodeLinker: pnp
pnpMode: loose

En un proyecto PnP, .yarn/lo más probable es que la carpeta contenga una sdk/carpeta para proporcionar compatibilidad con IDE además de una releases/carpeta. Hay incluso más carpetas que pueden formar parte de .yarn/, según su caso de uso.

.
├── .yarn/
│   ├── cache/
│   ├── releases/
│   │   └── yarn-3.1.1.cjs
│   ├── sdk/
│   └── unplugged/
├── .pnp.cjs
├── .pnp.loader.mjs
├── .yarnrc.yml
├── package.json
└── yarn.lock

pnpm

El estado inicial de un proyecto pnpm se parece a un proyecto npm o Yarn Classic: necesita un package.jsonarchivo. Después de instalar las dependencias con , se genera $ pnpm iuna carpeta, pero su estructura es completamente diferente debido a su enfoque de almacenamiento direccionable por contenido.node_modules

pnpm también genera su propia versión de un archivo de bloqueo, pnp-lock.yml. Puede proporcionar una configuración adicional con un .npmrcarchivo opcional.

.
├── node_modules/
│   └── .pnpm/
├── .npmrc
├── package.json
└── pnpm-lock.yml

Bloquear archivos y almacenamiento de dependencias

Como se describe en la sección anterior, cada administrador de paquetes crea archivos de bloqueo .

Los archivos de bloqueo almacenan exactamente las versiones de cada dependencia instalada para su proyecto, lo que permite instalaciones más predecibles y deterministas. Esto es necesario porque las versiones de dependencia probablemente se declaran con rangos de versión (p. ej., ≥ v1.2.5) y, por lo tanto, las versiones realmente instaladas podrían diferir si no "bloquea" sus versiones.

Los archivos de bloqueo a veces también almacenan sumas de verificación, que trataremos con más detalle en nuestra sección sobre seguridad.

Los archivos de bloqueo han sido una característica de npm desde v5 ( package-lock.json), en pnpm desde el primer día ( pnpm-lock.yaml) y en un nuevo formato YAML en Yarn Berry ( yarn.lock).

En la sección anterior, vimos el enfoque tradicional, donde las dependencias se instalan en una node_modulesestructura de carpetas. Este es el esquema que utilizan npm, Yarn Classic y pnpm , donde pnpm lo hace de manera más eficiente que los demás.

Yarn Berry en modo PnP lo hace de manera diferente. En lugar de una node_modulescarpeta, las dependencias se almacenan como archivos zip en combinación con un archivo .yarn/cache/y ..pnp.cjs

Es mejor tener estos archivos bloqueados bajo el control de versiones porque resuelve el problema "funciona en mi máquina": todos los miembros del equipo instalan las mismas versiones.

Comandos CLI

Las siguientes tablas comparan un conjunto seleccionado de diferentes comandos CLI disponibles en npm, Yarn Classic, Yarn Berry y pnpm. Esta no es una lista completa, pero constituye una hoja de trucos. Esta sección no cubre los comandos relacionados con el espacio de trabajo.

npm y pnpm presentan especialmente muchos alias de comandos y opciones, lo que significa que los comandos pueden tener diferentes nombres, es decir, $ npm installes lo mismo que $ npm add. Además, muchas opciones de comandos tienen versiones cortas, por ejemplo, -Den lugar de --save-dev.

En las tablas, me referiré a todas las versiones cortas como alias. Con todos los administradores de paquetes, puede agregar, actualizar o eliminar varias dependencias separándolas con espacios (p. ej., npm update react react-dom). En aras de la claridad, los ejemplos solo muestran el uso con dependencias individuales.

Gestión de dependencias

Esta tabla cubre los comandos de administración de dependencias para instalar o actualizar todas las dependencias especificadas en package.json, o múltiples dependencias especificándolas en los comandos.

Acción	sobre el nivel del mar	Hilo clásico	Baya de hilo	pnpm
instalar deps enpackage.json	npm install alias: i,add	yarn installoyarn	como clásico	pnpm install alias:i
actualizar deps en package.jsonacc. sever	npm update alias: up,upgrade	yarn upgrade	yarn semver up(a través del complemento )	pnpm update alias:up
actualizar las dependencias package.jsona la última	N / A	yarn upgrade --latest	yarn up	pnpm update --latest alias:-L
actualizar deps acc. sever	npm update react	yarn upgrade react	yarn semver up react	pnpm up react
actualizar deps a la última	npm update react@latest	yarn upgrade react --latest	yarn up react	pnpm up -L react
actualizar deps de forma interactiva	N / A	yarn upgrade-interactive	yarn upgrade-interactive(a través del complemento )	$ pnpm up --interactive alias:-i
agregar dependencias de tiempo de ejecución	npm i react	yarn add react	como clásico	pnpm add react
añadir departamentos de desarrollo	npm i -D babel alias:--save-dev	yarn add -D babel alias:  --dev	como clásico	pnpm add -D babel alias:--save-dev
agregar deps a package.jsonsin semver	npm i -E react alias:--save-exact	yarn add -E react alias:--exact	como clásico	pnpm add -E react alias:--save-exact
desinstalar deps y eliminar depackage.json	npm uninstall react alias: remove, rm, r, un,unlink	yarn remove react	como clásico	pnpm remove react alias: rm, un,uninstall
desinstalar deps sin actualización depackage.json	npm uninstall  --no-save	N / A	N / A	N / A

Ejecución de paquetes

Los siguientes ejemplos muestran cómo administrar paquetes que constituyen herramientas de utilidad durante el tiempo de desarrollo, también conocidos como archivos binarios, como ntl , para ejecutar secuencias de comandos de forma interactiva. La terminología utilizada en la tabla:

• Paquete: dependencia o binario
• Binario: una utilidad ejecutable que se ejecuta desde node_modules/.bin/o .yarn/cache/(PnP)

Es importante comprender que Yarn Berry solo nos permite ejecutar archivos binarios que hemos especificado en nuestro campo package.jsono que están expuestos en su binmetacampo por razones de seguridad. pnpm presenta el mismo comportamiento de seguridad .

Acción	sobre el nivel del mar	Hilo clásico	Baya de hilo	pnpm
instalar paquetes globalmente	npm i -g ntl alias:--global	yarn global add ntl	N/A ( global eliminado )	pnpm add --global ntl
actualizar paquetes globalmente	npm update -g ntl	yarn global upgrade ntl	N / A	pnpm update --global ntl
eliminar paquetes globalmente	npm uninstall -g ntl	yarn global remove ntl	N / A	pnpm remove --global ntl
ejecutar binarios desde la terminal	npm exec ntl	yarn ntl	yarn ntl	pnpm ntl
ejecutar binarios desde el script	ntl	ntl	ntl	ntl
ejecución de paquetes dinámicos	npx ntl	N / A	yarn dlx ntl	pnpm dlx ntl
agregar dependencias de tiempo de ejecución	npm i react	yarn add react	como clásico	pnpm add react
añadir departamentos de desarrollo	npm i -D babel alias:--save-dev	yarn add -D babel alias:--dev	como clásico	pnpm add -D babel alias:--save-dev
agregar deps a package.jsonsin semver	npm i -E react alias:--save-exact	yarn add -E react alias:--exact	como clásico	pnpm add -E react alias:--save-exact
desinstalar deps y eliminar depackage.json	npm uninstall react alias: remove, rm, r, un,unlink	yarn remove react	como clásico	pnpm remove react alias: rm, un,uninstall
desinstalar deps sin actualización depackage.json	npm uninstall --no-save	N / A	N / A	N / A

Comandos comunes

Esta tabla cubre útiles comandos incorporados. Si no hay un comando oficial, a menudo se puede usar un comando de terceros, a través de un paquete npm o un complemento de Yarn Berry.

Acción	sobre el nivel del mar	Hilo clásico	Baya de hilo	pnpm
publicar paquete	npm publish	yarn publish	yarn npm publish	pnpm publish
lista de unidades instaladas	npm ls alias: list, la,ll	yarn list		pnpm list alias:ls
lista de dependencias obsoletas	npm outdated	yarn outdated	yarn upgrade-interactive	pnpm outdated
imprimir información sobre deps	npm explain ntl alias:why	yarn why ntl	como clásico	pnpm why ntl
proyecto de inicio	npm init -y npm init(interactivo) alias:--yes	yarn init -y yarn init(interactivo) alias:--yes	yarn init	pnpm init -y pnpm init(interactivo) alias:--yes
imprimir información de licencias	N/A (a través de un paquete de terceros)	yarn licenses list	N/A (o a través de un complemento , otro complemento )	N/A (a través de un paquete de terceros)
actualizar la versión del administrador de paquetes	N/A (con herramientas de terceros, por ejemplo, nvm)	con npm:yarn policies set-version 1.13.0	con paquete básico:yarn set version 3.1.1	N/A (con npm, Corepack)
realizar auditoria de seguridad	npm audit	yarn audit	yarn npm audit	pnpm audit
agregar deps a package.jsonsin semver	npm i -E react alias:--save-exact	yarn add -E react alias:--exact	como clásico	pnpm add -E react alias:--save-exact
desinstalar deps y eliminar depackage.json	npm uninstall react alias: remove, rm, r, un,unlink	yarn remove react	como clásico	pnpm remove react alias: rm, un,uninstall
desinstalar deps sin actualización depackage.json	npm uninstall --no-save	N / A	N / A	N / A

Archivos de configuración

La configuración de los administradores de paquetes se lleva a cabo tanto en sus package.jsonarchivos de configuración como en los dedicados. Ejemplos de opciones de configuración son:

• Definir la versión exacta a utilizar
• Usar una estrategia particular de resolución de dependencia
• Configurar el acceso a un registro privado
• Dígale al administrador de paquetes dónde encontrar espacios de trabajo dentro de un monorepo

sobre el nivel del mar

La mayor parte de la configuración tiene lugar en un archivo de configuración dedicado ( .npmrc).

Si desea utilizar la función de espacios de trabajo de npm, debe agregar una configuración package.jsonmediante el campo de metadatos de espacios de trabajo para indicarle a npm dónde encontrar las carpetas que constituyen subproyectos o espacios de trabajo, respectivamente.

{
  // ...
  "workspaces": [
    "hooks",
    "utils"
  ]
}

Cada administrador de paquetes funciona de manera inmediata con el registro público de npm. En el contexto de una empresa con bibliotecas compartidas, lo más probable es que desee reutilizarlas sin publicarlas en un registro público. Para configurar un registro privado, puede hacerlo en un .npmrcarchivo.

# .npmrc
@doppelmutzi:registry=https://gitlab.doppelmutzi.com/api/v4/projects/41/packages/npm/

Existen muchas opciones de configuración para npm y se ven mejor en los documentos.

Hilo clásico

Puede configurar espacios de trabajo de Yarn en su archivo package.json. Es similar a npm, pero el espacio de trabajo debe ser un paquete privado.

{
  // ...
  "private": true,
  "workspaces": ["workspace-a", "workspace-b"]
}

Cualquier configuración opcional va a un .yarnrcarchivo . Una opción de configuración común es establecer un yarn-path, que impone una versión binaria particular para que la use cada miembro del equipo. El yarn-pathdirige a una carpeta (p. ej., .yarn/releases/) que contiene una versión particular de Yarn. Puede instalar una versión de Yarn Classic con el yarn policiescomando .

Baya de hilo

La configuración de espacios de trabajo en Yarn Berry también es análoga a cómo se hace en Yarn Classic, con un archivo package.json. La mayor parte de la configuración de Yarn Berry tiene lugar en .yarnrc.yml, y hay muchas opciones de configuración disponibles. El ejemplo de Yarn Classic también es posible, pero el campo de metadatos se renombra a yarnPath.

# .yarnrc.yml
yarnPath: .yarn/releases/yarn-3.1.1.cjs

Yarn Berry se puede ampliar con complementos mediante el uso de yarn plugin import. Este comando actualiza el .yarnrc.yml.

# .yarnrc.yml
plugins:
  - path: .yarn/plugins/@yarnpkg/plugin-semver-up.cjs
    spec: "https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js"

Como se describe en la sección de historial, puede haber problemas con las dependencias en el modo estricto PnP debido a la incompatibilidad. Existe una solución típica para un problema PnP de este tipo: la packageExtensionspropiedad de configuración . Puede seguir el siguiente ejemplo con el proyecto complementario .

# .yarnrc.yml
packageExtensions:
  "styled-components@*":
    dependencies:
      react-is: "*"

pnpm

pnpm usa el mismo mecanismo de configuración que npm , por lo que puede usar un .npmrcarchivo. La configuración de un registro privado también funciona de la misma manera que con npm.

Con la característica de espacios de trabajo de pnpm , está disponible el soporte para proyectos de paquetes múltiples. Para inicializar un monorepo, debe especificar la ubicación de los paquetes en un pnpm-workspace.yamlarchivo.

# pnpm-workspace.yaml
packages:
  - 'packages/**'

soporte Monorepo

¿Qué es un monorepo?

Un monorepo es un repositorio que alberga múltiples proyectos, que se denominan espacios de trabajo o paquetes. Es una estrategia de organización de proyectos para mantener todo en un solo lugar en lugar de usar múltiples repositorios.

Por supuesto, esto viene con una complejidad adicional. Yarn Classic fue el primero en habilitar esta funcionalidad, pero ahora todos los principales administradores de paquetes ofrecen una función de espacios de trabajo. Esta sección muestra cómo configurar espacios de trabajo con cada uno de los diferentes administradores de paquetes.

sobre el nivel del mar

El equipo de npm lanzó la tan esperada función de espacios de trabajo de npm en v7. Contenía una serie de comandos CLI que ayudaron a administrar proyectos de paquetes múltiples desde un paquete raíz. La mayoría de los comandos se pueden usar con opciones relacionadas con el espacio de trabajo para decirle a npm si debe ejecutarse en un espacio de trabajo específico, en varios o en todos.

# Installing all dependencies for all workspaces
$ npm i --workspaces.
# run against one package
$ npm run test --workspace=hooks
# run against multiple packages
$ npm run test --workspace=hooks --workspace=utils
# run against all
$ npm run test --workspaces
# ignore all packages missing test
$ npm run test --workspaces --if-present

A diferencia de otros administradores de paquetes, npm v8 actualmente no admite el filtrado avanzado ni la ejecución de varios comandos relacionados con el espacio de trabajo en paralelo.

Hilo clásico

En agosto de 2017, el equipo de Yarn anunció soporte monorepo de primera clase en términos de una función de espacios de trabajo . Antes de este punto, solo era posible usar un administrador de paquetes en un proyecto de paquetes múltiples con software de terceros como Lerna . Esta adición a Yarn allanó el camino para que otros administradores de paquetes también implementaran dicha función.

También he escrito anteriormente sobre cómo usar la función de espacios de trabajo de Yarn Classic con y sin Lerna, si está interesado. Pero esta publicación solo cubrirá algunos comandos necesarios para ayudarlo a administrar las dependencias en una configuración de espacios de trabajo de Yarn Classic.

# Installing all dependencies for all workspaces
$ yarn
# display dependency tree
$ yarn workspaces info
# run start command only for one package
$ yarn workspace awesome-package start
# add Webpack to package
$ yarn workspace awesome-package add -D webpack
# add React to all packages
$ yarn add react -W

Baya de hilo

Yarn Berry presentó espacios de trabajo desde el principio porque su implementación se basó en los conceptos de Yarn Classic. En un comentario de Reddit , un desarrollador principal de Yarn Berry dio una breve descripción general de las funciones orientadas al espacio de trabajo, que incluyen:

• $ yarn add --interactive: permite reutilizar versiones de otros espacios de trabajo al instalar un paquete
• $ yarn up: actualiza un paquete en todos los espacios de trabajo
• $ yarn workspaces focus: instala dependencias solo para un único espacio de trabajo
• $ yarn workspaces foreach: ejecuta un comando en todos los espacios de trabajo

Yarn Berry hace un uso intensivo de los protocolos , que se pueden usar en los campos dependencieso de los archivos. Uno de ellos es el protocolo .devDependenciespackage.jsonworkspace:

A diferencia de los espacios de trabajo de Yarn Classic, Yarn Berry define explícitamente que una dependencia debe ser uno de los paquetes de este monorrepositorio. De lo contrario, Yarn Berry podría intentar obtener una versión de un registro remoto si las versiones no coinciden.

{
  // ...
  "dependencies": {
    "@doppelmutzi/hooks": "workspace:*",
    "http-server": "14.0.0",
    // ...
  }  
}

pnpm

Con su workspace:protocolo, pnpm facilita proyectos monorepo de manera similar a Yarn Berry. Muchos comandos pnpm aceptan opciones como --recursive( -r) o --filterque son especialmente útiles en un contexto monorepo. Su comando de filtrado nativo también es un buen complemento o reemplazo para Lerna.

# prune all workspaces  
pnpm -r exec -- rm -rf node_modules && rm pnpm-lock.yaml  
# run all tests for all workspaces with scope @doppelmutzi
pnpm recursive run test --filter @doppelmutzi/

Rendimiento y eficiencia del espacio en disco

El rendimiento es una parte crucial de la toma de decisiones. Esta sección muestra mis puntos de referencia basados ​​en un proyecto pequeño y uno mediano. Aquí hay algunas notas sobre los proyectos de muestra:

• Ningún conjunto de puntos de referencia utiliza funciones de espacio de trabajo
• El pequeño proyecto especifica 33 dependencias.
• El proyecto mediano especifica 44 dependencias.

Realicé mediciones para tres casos de uso (UC), una vez para cada una de nuestras variantes de administrador de paquetes. Para conocer la evaluación detallada con explicaciones, echa un vistazo a los resultados del proyecto 1 (P1) y del proyecto 2 (P2) .

• UC 1: Sin caché/almacén, sin archivos de bloqueo, sin node_moduleso.pnp.cjs
• UC 2: existe caché/almacenamiento, no hay archivos de bloqueo, no node_moduleso.pnp.cjs
• UC 3: existe caché/almacenamiento, existen archivos de bloqueo, no node_moduleso.pnp.cjs

Usé la herramienta gnomon para medir el tiempo que consume una instalación (por ejemplo, $ yarn | gnomon). Además, medí los tamaños de los archivos generados, por ejemplo, $ du -sh node_modules.

Con mis proyectos y mis medidas, Yarn Berry PnP strict fue el ganador en términos de velocidad de instalación para todos los casos de uso y ambos proyectos.

Resultados de desempeño para el Proyecto 1
Método	npm v8.1.2	Hilo clásico v1.23.0	pnpm v6.24.4	Hilo Berry PnP suelto v3.1.1	Hilo Berry PnP estricto v3.1.1	Baya de hilo node_modules v3.1.1	Hilo Berry pnpm v3.1.1
CU 1	86.63s	108.89s	43.58s	31.77s	30.13 s	56.64s	60.91s
CU 2	41.54s	65.49s	26.43 s	12.46s	12,66 s	46.36s	40.74s
CU 3	23.59s	40.35s	20.32s	1,61 s	1,36 s	28.72s	31.89s
archivos y tamaño	package-lock.json: 1.3M node_modules: 467M	node_modules: 397M yarn.lock: 504K	pnpm-lock.yaml: 412K node_modules: 319M	yarn.lock: 540K caché: 68M desenchufado: 29M .pnp.cjs: 1,6M	yarn.lock: 540K caché: 68M desenchufado: 29M .pnp.cjs: 1,5M	node_modules: 395M yarn.lock: 540K caché: 68M	node_modules: 374M yarn.lock: 540K caché: 68M

 

Resultados de desempeño para el Proyecto 2
Método	npm v8.1.2	Hilo clásico v1.23.0	pnpm v6.24.4	Hilo Berry PnP suelto v3.1.1	Hilo Berry PnP estricto v3.1.1	Baya de hilo node_modules v3.1.1	Hilo Berry pnpm v3.1.1
CU 1	34.91s	43.26s	15,6 s	13.92s	6.44s	23.62s	20.09s
CU 2	7.92s	33.65s	8.86s	7.09s	5,63 s	15.12 s	14.93 s
CU 3	5.09s	15.64 s	4,73 s	0,93 s	0,79 s	8.18 s	6.02s
archivos y tamaño	package-lock.json: 684K node_modules: 151M	yarn.lock: 268K node_modules: 159M	pnpm-lock.yaml: 212K node_modules: 141M	.pnp.cjs: 1.1M : .pnp.loader.mjs8.0K yarn.lock: 292K .yarn: 38M	.pnp.cjs: 1.0M .pnp.loader.mjs: 8.0K yarn.lock: 292K .yarn: 38M	yarn.lock: 292K node_modules: 164M caché: 34M	yarn.lock: 292K node_modules: 156M caché: 34M

Estos son los puntos de referencia oficiales del equipo de Yarn Berry y de pnpm .

Características de seguridad

sobre el nivel del mar

npm ha sido demasiado indulgente cuando se trata de trabajar con paquetes defectuosos y ha experimentado algunas vulnerabilidades de seguridad que afectaron directamente a muchos proyectos. Por ejemplo, en la versión 5.7.0, cuando ejecutaba el sudo npmcomando en un sistema operativo Linux, era posible cambiar la propiedad de los archivos del sistema, lo que hacía que el sistema operativo quedara inutilizable.

Otro incidente ocurrió en 2018 e involucró el robo de Bitcoin. Básicamente, el popular paquete EventStream de Node.js agregó una dependencia maliciosa en su versión 3.3.6. Este paquete malicioso contenía una carga útil encriptada que intentaba robar Bitcoin de la máquina del desarrollador.

Para ayudar a resolver estos problemas, las versiones más recientes de npm utilizan el SHA-512algoritmo de criptografía package-lock.jsonpara verificar la integridad de los paquetes que instala.

En general, npm ha hecho cada vez más para cerrar sus brechas de seguridad, especialmente aquellas que se hicieron más obvias en comparación con Yarn.

Hilo

Tanto Yarn Classic como Yarn Berry han verificado la integridad de cada paquete con sumas de verificación almacenadas yarn.lockdesde el principio. Yarn también intenta evitar que recuperes paquetes maliciosos que no están declarados en tu package.jsondurante la instalación: si se encuentra una discrepancia, la instalación se cancela.

Yarn Berry en modo PnP no sufre los problemas de seguridad del node_modulesenfoque tradicional. A diferencia de Yarn Classic, Yarn Berry mejora la seguridad de la ejecución de comandos. Solo puede ejecutar binarios de dependencias que haya declarado explícitamente en su archivo package.json. Esta función de seguridad es similar a pnpm, que describiré a continuación.

pnpm

pnpm también usa sumas de verificación para verificar la integridad de cada paquete instalado antes de que se ejecute su código.

Como mencionamos anteriormente, npm y Yarn Classic tienen problemas de seguridad debido a la elevación . pnpm evita esto porque su modelo no usa elevación; en su lugar, genera node_modulescarpetas anidadas que eliminan el riesgo de acceso de dependencia ilegal. Esto significa que las dependencias solo pueden acceder a otras dependencias si se declaran explícitamente en package.json.

Esto es especialmente crucial en una configuración monorepo, como comentamos, porque el algoritmo de elevación a veces puede conducir a dependencias fantasma y doppelgangers .

Adopción por proyectos populares

Analicé muchos proyectos populares de código abierto para tener una idea de qué administradores de paquetes usa hoy en día la "élite de desarrolladores". Era importante para mí que estos proyectos se mantuvieran activamente y se actualizaran por última vez recientemente. Esto podría darle otra perspectiva al elegir un administrador de paquetes.

sobre el nivel del mar	Hilo clásico	Baya de hilo	pnpm
Esbelto	Reaccionar	es (con node_modules)	Ver 3
Preactuar	Angular	Libro de cuentos (con node_modules)	lista de navegadores
Express.js	Humano	Babel (con node_modules)	Prisma
Meteorito	Siguiente.js	Kit de herramientas Redux (con node_modules)	SvelteKit
Servidor Apolo	gatsby
	Siguiente
	Crear aplicación de reacción
	webpack-cli
	Emoción

Curiosamente, en el momento de escribir este artículo, ninguno de estos proyectos de código abierto utiliza un enfoque PnP.

Conclusión

El estado actual de los administradores de paquetes es excelente. Prácticamente hemos alcanzado la paridad de características entre todos los principales administradores de paquetes. Pero aún así, difieren bastante bajo el capó.

pnpm se parece a npm al principio porque su uso de CLI es similar, pero la administración de dependencias es muy diferente; El método de pnpm conduce a un mejor rendimiento y la mejor eficiencia de espacio en disco. Yarn Classic sigue siendo muy popular, pero se considera un software heredado y es posible que el soporte se elimine en un futuro próximo. Yarn Berry PnP es el nuevo chico del bloque, pero no se ha dado cuenta completamente de su potencial para revolucionar el panorama de los administradores de paquetes una vez más.

A lo largo de los años, muchos usuarios han preguntado quién usa qué administradores de paquetes y, en general, parece que la gente está especialmente interesada en la madurez y adopción de Yarn Berry PnP.

El objetivo de este artículo es brindarle muchas perspectivas para que tome una decisión sobre qué administrador de paquetes usar por su cuenta. Me gustaría señalar que no recomiendo un administrador de paquetes en particular. Depende de cómo sopeses los diferentes requisitos, ¡así que aún puedes elegir lo que quieras! 

Fuente: https://blog.logrocket.com/javascript-package-managers-compared/

#javascript #yarn #npm #pnpm 

NPM vs Yarn | Which is the Best Package Manager?

In this video I talk about whether you should use NPM or Yarn as your package manager.

#npm #node #yarn #javascript

Npm VS Yarn the right package manager for you

Npm

• Nodejs Default Package Manager

• Fetches every package independently

• Large support community

• Easy for beginners and straight to the point

Yarn

• Alternative-Optimized Package Manager

• Faster when it comes to fetching multiple packages

• Caches All packages for quicker fetching

• Has to install it separately by yourself

• Say goodbye to “It works on my machine”

When it comes to package installation or updates Yarn is much faster compared to Npm since it uses a simultaneous package fetching and installation technique.

For a javascript developer and a web developer both of Npm and Yarn does a great job maintaining and managing your project dependencies they both offer a great set of features and reliability and a large supportive community of experienced developers.

#npm #yarn #javascript #developer

How to Install Yarn on Ubuntu 18.04

In this tutorial, we will explain how to install the Yarn package manager via the Yarn repository on your Ubuntu 18.04 system. This repo is well maintained and consistently provides the most up-to-date version available. We will also present some of the basic Yarn commands and options.

Yarn can be installed using the following npm command although it is not recommended. We only mention this to show how it can be installed using nmp.

#java #javascript #node.js #npm #npm registry #packages #ubuntu 18.04 #yarn