Comparación de administradores de paquetes de JavaScript: Npm vs Yarn vs Pnpm

Hay tres actores principales en el espacio del administrador de paquetes:

• npm

• Yarn

• High-Performance npm (pnpm)

En realidad, tenemos una funcionalidad básicamente similar implementada en todos los administradores de paquetes, por lo que lo más probable es que usted decida cuál usar según los requisitos no funcionales. Administrador de paquetes , como la velocidad de instalación, el consumo de almacenamiento o la practicidad.

Por supuesto, la forma en que elija utilizar cada administrador de paquetes será diferente, pero todos tienen conceptos básicamente consistentes. Todos los administradores de paquetes anteriores pueden realizar los siguientes comandos:

• Leer y escribir datos
• Instalar por lotes o actualizar todas las dependencias
• Agregar, actualizar y eliminar dependencias
• Ejecutar scripts
• Publicar paquetes

Sin embargo, a pesar de esto, los administradores de paquetes son diferentes internamente. Tradicionalmente, npm y Yarn instalaban dependencias en una carpeta plana node_modules. (Preste atención al orden aquí, yarn se coloca primero en mosaico y npm era recursivo antes). Pero el mosaico también puede provocar una serie de problemas de seguridad.

• Incertidumbre de la estructura de dependencia.

• El algoritmo de aplanamiento en sí es muy complejo y requiere mucho tiempo.

• Aún se puede acceder ilegalmente a

• los paquetes con dependencias declaradas

en el proyecto.

Por lo tanto, pnpm ha introducido algunos conceptos nuevos en la carpeta node_modules para almacenar dependencias de manera más eficiente. Yarn Berry incluso va más allá al abandonar por completo el modo (PnP) de node_modules (más sobre esto en otro artículo).

Una breve historia de los paquetes de JavaScript

El primer administrador de paquetes lanzado fue npm , en enero de 2010. Estableció los principios básicos de cómo funcionan los administradores de paquetes en la actualidad. Pero dado que npm existe desde hace más de 10 años, ¿por qué existe otra opción? A continuación se presentan algunas razones clave por las que este podría ser el caso:

• node_modules tiene diferentes algoritmos de resolución de dependencias (anidados y en mosaico, node_modules versus modo PnP) y
• diferentes métodos de elevación de dependencias ( hoisting ).
• Diferentes formatos locking (rendimiento diferente, como el escrito por el propio yarn ).
• Paquete de almacenamiento en disco. Archivo diferente. formatos (diferente eficiencia de espacio)
• Diferentes soportes para proyectos de paquetes múltiples (también conocidos como workspaces ) que afectan la capacidad de mantenimiento y la velocidad de monorepos
• Diferentes necesidades de nuevas herramientas y comandos (diferentes necesidades de extensibilidad a través de complementos y herramientas comunitarias)
• Configurabilidad y flexibilidad de manera diferente

Profundicemos en la historia de cómo se determinaron estos aspectos después del surgimiento de npm , cómo Yarn Classic resolvió algunos de estos problemas, cómo pnpm amplió estos conceptos y cómo Yarn Berry , como sucesor de Yarn Classic rompe estos conceptos y procesos tradicionales.

Pioneer npm

npm es el creador de los administradores de paquetes. Mucha gente cree erróneamente que npm es el acrónimo de "Administrador de paquetes de nodos", pero no es así.

Su lanzamiento constituyó una revolución porque antes las dependencias de los proyectos se descargaban y gestionaban manualmente. npm introdujo cosas como archivos y sus campos de metadatos, almacenamiento de dependencias en node_modules , scripts personalizados, paquetes públicos y privados, y más.

En 2020, GitHub adquirió npm, por lo que, en principio, npm ahora lo administra Microsoft. En el momento de redactar este artículo, la última versión principal es la v8, lanzada en octubre de 2021.

Innovator Yarn Classic

En octubre de 2016, Facebook anunció una asociación con Google y varias otras empresas para desarrollar un nuevo administrador de paquetes (engineering.fb.com/2016/10/11/…) para abordar la coherencia existente en ese momento de npm. Problemas de seguridad y rendimiento. Llamaron al reemplazo Yarn.

Aunque Yarn todavía está diseñado y diseñado en base a muchos conceptos y procesos de npm , Yarn ha tenido un impacto significativo en el campo del administrador de paquetes. En comparación con npm , Yarn paraleliza las operaciones para acelerar el proceso de instalación, lo que ha sido un problema importante con las versiones anteriores de npm .

Yarn estableció estándares más altos para lectura y escritura, seguridad y rendimiento, e inventó muchos conceptos (más tarde, npm también hizo muchas mejoras para esto), que incluyen:

• monorepo admite
• almacenamiento en caché, instalación de
bloqueo de archivos
• de descarga sin conexión
• ( Locking )

Yarn v1 en Entrar en modo de mantenimiento en 2020. Desde entonces, la serie v1.x se considera heredada y se renombra como Yarn Classic . Su sucesor Yarn v2 (Berry) es ahora la rama de desarrollo más activa.

pnpm más eficiente

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

La razón principal por la que se creó pnpm es que npm y Yarn son muy redundantes en términos de estructuras de almacenamiento de dependencia utilizadas en todos los proyectos. Aunque Yarn Classic tiene una ventaja de velocidad sobre npm , utiliza el mismo método de resolución de dependencias que pnpm no: npm y Yarn Classic usan hoisting para aplanar sus node_modules .

En lugar de optimizar la estructura anterior, pnpm introduce otra estrategia de resolución de dependencias: a. estructura de almacenamiento dirigida a contenidos. La carpeta node_modules generada por este método en realidad depende del directorio ~/.pnpm-store/ que está almacenado globalmente en la carpeta principal. Cada versión de las dependencias se almacena físicamente una vez en esta carpeta de directorio, formando una única dirección de origen para ahorrar un espacio considerable en el disco.

La estructura node_modules es una estructura anidada de dependencias creada mediante el uso de symlinks (donde cada archivo/paquete dentro de una carpeta se almacena a través de un enlace físico). La siguiente figura de la documentación oficial ilustra esto. (Imágenes para completar: enlaces físicos y blandos)

La influencia de pnpm es visible en el informe de 2021: debido a sus innovaciones en el almacenamiento direccionable de contenido, los competidores buscan adoptar conceptos pnpm , como la estructura de enlaces simbólicos y la gestión eficiente de paquetes en disco.

Yarn (v2, Berry), que 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 Yarn lo llama Yarn Berry para que sea más obvio que es 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-and-play (PnP) como estrategia para reparar node_modules. En lugar de la estrategia de generar node_modules , genere un archivo .pnp.cjs con una tabla de búsqueda de dependencias, lo que permite un manejo más eficiente de las dependencias ya que es un archivo único en lugar de una estructura de carpetas anidadas. Además, cada paquete se almacena en una carpeta en forma de archivo zip en lugar de .yarn/cache/ y ocupa menos espacio en disco que node_modules .

Todos estos cambios ocurrieron tan rápido que causaron mucha controversia después de su lanzamiento. Estos cambios importantes en PnP requieren que los mantenedores actualicen sus paquetes existentes para que sean compatibles con él. Usar el nuevo enfoque PnP de forma predeterminada y volver a node_modules no fue sencillo inicialmente, lo que llevó a que muchos desarrolladores conocidos no lo consideraran y criticaran públicamente a Yarn 2.

Desde entonces, el equipo Yarn Berry ha abordado muchos problemas en sus versiones posteriores. Para resolver los problemas de incompatibilidad de PnP, el equipo ha proporcionado una manera de cambiar fácilmente el modo operativo predeterminado. Con la ayuda del complemento node_modules, volver al enfoque tradicional node_modules solo requiere una línea de configuración.

Además, el ecosistema JavaScript ha brindado un soporte cada vez mayor para PnP con el tiempo y, como puede ver en esta tabla de compatibilidad, algunos proyectos grandes han comenzado a adoptar Yarn Berry .

Aunque Yarn Berry todavía es joven, ya está teniendo un impacto en el espacio de gestión de paquetes: pnpm adoptó el enfoque PnP a finales de 2020.

Flujo de trabajo de instalación

El administrador de paquetes primero debe instalarse en los sistemas CI/CD locales y de cada desarrollador.

npm

npm viene con Node.js , por lo que no se requieren pasos adicionales. Además de descargar el instalador de Node.js para su sistema operativo, se ha convertido en una práctica común utilizar herramientas CLI para administrar las versiones de software. En el contexto de Node, Node Version Manager (nvm) o Volta se han convertido en una utilidad muy conveniente.

Yarn Classic y Yarn Berry

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

Para migrar de Yarn Classic a Yarn Berry, el método recomendado es:

• Instalar o actualizar Yarn Classic a

To actualice a la última

• versión

moderna,

• use el comando

  Yarn Set Version Berry.

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

Corepack fue creado por los desarrolladores de Yarn Berry. La iniciativa originalmente se llamó Package Manager Manager (pmm) y se fusionó con Node en LTS v16.

Con la ayuda de Corepack, Node es un administrador de paquetes alternativo a npm que no es necesario instalar "por separado", ya que incluye los binarios Yarn Classic , Yarn Berry y pnpm . Estas correcciones permiten a los usuarios ejecutar comandos Yarn y pnpm sin instalarlos explícitamente primero y sin estropear la distribución de Node.

Corepack viene preinstalado con Node.js ≥ v16.9.0. Sin embargo, para versiones anteriores de Node, puede usar ⬇️

npm install -g corepack

para habilitar Corepack antes de usarlo. Este ejemplo muestra cómo activarlo en Yarn Berry v3.1.1.

# primero debes registrarte
$ paquete central habilitado
# cuña instalada pero es necesario activar la versión concreta
$ corepack prepare [email protected] --activate

pnpm

Puede instalar pnpm como un paquete npm : $ npm i -g pnpm . También puede instalar pnpm usando Corepack:

$ corepack prepare [email protected] --activar

estructura del proyecto

En esta sección verás de un vistazo las principales características de los diferentes gestores de paquetes. Puede descubrir fácilmente qué archivos están involucrados en la configuración de un administrador de paquetes específico y qué archivos se generan en el 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, los archivos de configuración de nivel raíz se pueden utilizar para configurar diferentes paquetes privados o diferentes configuraciones de resolución de dependencias.

Durante el paso de instalación, dependencies se almacenan en una estructura de archivos como node_modules y se genera un archivo locking . Esta sección no considera la configuración del espacio de trabajo, por lo que todos los ejemplos solo muestran una ubicación única donde se almacenan las dependencias.

npm

usando $ npm install o el $ npm i más corto, generaré un archivo package-lock.json y una carpeta node_modules . También hay archivos configurables como .npmrc que se pueden colocar en el directorio de nivel raíz. Consulte la siguiente sección para obtener más información sobre locking archivos.

.
├── módulos_nodo/
├── .npmrc
├── paquete-lock.json
└── package.json

hilo

ejecutando $ yarn creará un archivo yarn.lock y una carpeta node_modules . Los archivos .yarnrc también pueden ser opciones de configuración, y Yarn Classic también admite archivos .npmrc . Alternativamente, puede usar la carpeta de caché .yarn/cache/ y la última versión Yarn Classic almacenada localmente en .yarn/releases/ .

.
├── .hilo/
│ ├── caché/
│ └── lanzamientos/
│ └── hilo-1.22.17.cjs
├── módulos_nodo/
├── .yarnrc
├── paquete.json
└── Yarn.lock

Yarn Berry: node_modules

Debido a este modo de instalación especial, tienes que manejar más archivos y carpetas en tu proyecto Yarn Berry que con otros administradores de paquetes. Algunas son opcionales y otras obligatorias.

Yarn Berry ya no admite .npmrc o .yarnrc ; requiere .yarnrc.yml. Para el flujo de trabajo tradicional de generar carpetas node_modules , debe proporcionar la configuración nodeLinker para usar la configuración node_modules o pnpm (no entiendo esta parte).

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

ejecutando $ yarn instalará todas las dependencias en una carpeta node_modules . Y se genera un archivo yarn.lock , que es más nuevo pero no compatible con Yarn Classic . Además, se genera una carpeta .yarn/cache/ para la instalación sin conexión. Esta carpeta es opcional y se utiliza para almacenar la versión de Yarn Berry utilizada por el proyecto.

.
├── .hilo/
│ ├── caché/
│ └── lanzamientos/
│ └── hilo-3.1.1.cjs
├── módulos_nodo/
├── .yarnrc.yml
├── paquete.json
└── hilo.lock

hilo baya: pnp

Ya sea en modo estricto o modo suelto para PnP, ejecutar $ yarn con .pnp.cjs y yarn.lock generará un .yarn/cache/ y .yarn/unplugged . PnP estricto es el modo predeterminado. Si desea configurar el modo suelto, debe habilitarlo de la siguiente forma⬇️:

# .yarnrc.yml.
enlazador de nodos: pnp
pnpMode: suelto

En un proyecto PnP, además de la carpeta releases , es probable que la carpeta .yarn también contenga una carpeta sdk/ que proporciona soporte IDE. Dependiendo de su caso de uso, .yarn puede incluso contener más carpetas.

.
├── .hilo/
│ ├── caché/
│ ├── lanzamientos/
│ │ └── hilo-3.1.1.cjs
│ ├── SDK/
│ └── desconectado/
├── .pnp.cjs
├── .pnp.loader.mjs
├── .yarnrc.yml
├── paquete.json
└── Yarn.lock`

pnpm

package.json el mismo que el npm o el proyecto Yarn Classic y también requiere el archivo pnpm . Después de instalar dependencias usando $ pnpm i , obtengo una carpeta node_modules , pero su estructura es completamente diferente ya que su contenido es almacenamiento direccionable.

pnpm también genera su propio archivo de bloqueo pnp-lock.yml . Puede proporcionar configuración adicional utilizando el archivo .npmrc opcional.

.
├── módulos_nodo/
│ └── .pnpm/
├── .npmrc
├── paquete.json
└── archivo de bloqueo pnpm-lock.yml

y almacenamiento dependiente

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

El archivo lock almacena la versión exacta de cada dependencia instalada por su proyecto, lo que permite una instalación más predecible y determinista. Este archivo lock es importante porque es probable que las versiones dependientes se declaren con un rango de versiones (por ejemplo, ≥ v1.2.5) y si no "bloquea" su versión, la versión real instalada puede ser diferente.

Los archivos de bloqueo a veces también almacenan sumas de verificación (un hash, según recuerdo), que cubriremos con más profundidad en la sección de seguridad.

A partir de npm v5+, bloquear archivos siempre ha sido la función principal de npm ( package-lock.json ). En pnpm , es pnpm-lock.yaml . yarn.lock en Yarn Berry aparece en el nuevo formato YAML.

En la sección anterior vimos el enfoque tradicional de instalar dependencias en la estructura de carpetas node_modules . Esta es la solución utilizada por npm , Yarn Classic y pnpm ( pnpm es más eficiente que los demás).

Yarn Berry hace las cosas de manera diferente en el modo PnP. En lugar de la carpeta node_modules , las dependencias se almacenan en archivos zip como una combinación de archivos .yarn/cache/ y .pnp.cjs .

Es mejor poner estos archivos bloqueados bajo control de versiones, ya que cada miembro del equipo instala la misma versión, por lo que resuelve el problema de "funciona en tu máquina y en la mía".

CLI

La siguiente tabla compara los diferentes comandos CLI disponibles en npm , Yarn Classic , Yarn Berry y pnpm . Esta no es de ninguna manera una lista completa, sino más bien una hoja de referencia. Esta sección no cubre los comandos relacionados con el flujo de trabajo.

npm y pnpm tienen muchos alias de opciones y comandos ad hoc, lo que significa que los comandos pueden tener nombres diferentes, es decir, $ npm install frente a $ npm add . Además, muchas opciones de comando tienen versiones abreviadas, como -D en lugar de --save-dev . En la tabla, llamo alias a todas las versiones abreviadas. Con cada uno de estos administradores de paquetes, puede agregar, actualizar o eliminar múltiples dependencias.

Gestión de configuración de dependencias

Esta tabla cubre los comandos de gestión de dependencias utilizados para instalar o actualizar todas las dependencias especificadas en package.json .

Gestión de la configuración de la instalación

El siguiente ejemplo muestra cómo gestionar paquetes durante el desarrollo. Términos utilizados en la tabla:

• Paquete: dependencia o binario
• Binario: Una herramienta de ejecución desde node_modules/.bin/ o .yarn/cache/ (PnP)

Es importante entender que Yarn Berry solo nos permite ejecutar en package.json o Expose los archivos binarios especificados en el archivo bin/ .

Comandos comunes

Esta tabla cubre algunos comandos integrados útiles. Si no existe un comando oficial, los comandos de terceros generalmente se pueden usar a través de paquetes npm o complementos Yarn Berry .

Archivo de configuración

La configuración del administrador de paquetes se realiza en su package.json y en los archivos de configuración dedicados.

• Defina la versión exacta que se utilizará
• Configure el registro privado
• con una estrategia de resolución de dependencia específica
• Indique al administrador de paquetes dónde encontrar el monorepo

npm

La mayor parte de la configuración ocurre en el archivo de configuración privado .npmrc .

Si desea utilizar la función workspaces de npm , debe agregar el campo de metadatos de espacios de trabajo en package.json para indicarle a npm dónde encontrar el subproyecto o la carpeta del espacio de trabajo.

//...
  "espacios de trabajo": [
    "manos",
    "utilidades"
  ]
}

Cada administrador de paquetes puede usar el registro público npm . Probablemente desee reutilizarlos sin publicarlos en un registro público. Puede configurar esto para que el registro sea privado en su archivo .npmrc . (Básicamente todos tienen fuentes privadas ahora)

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

Hay muchas opciones de configuración para npm , es mejor consultarlas en la documentación.

Yarn

Puede configurar workspaces de yarn en package.json (debe ser un paquete privado).

{
  //...
  "privado": verdadero,
  "espacios de trabajo": ["espacio de trabajo-a", "espacio de trabajo-b"]
}

Cualquier configuración opcional se guarda en un archivo .yarnrc . Una opción de configuración común es establecer una yarn-path: obliga a cada miembro del equipo a usar una versión binaria específica. yarn-path apunta a la carpeta que contiene una versión específica Yarn (por ejemplo, .yarn/releases/ ). Puede instalar la versión unificada Yarn Classic usando el comando (classic.yarnpkg.com/en/docs/cli…).

Yarn Berry

La configuración de workspaces en Yarn Berry es similar a la configuración en Yarn Classic ( package.json ). La mayor parte de la configuración Yarn Berry se produce en .yarnrc.yml y hay muchas opciones de configuración disponibles.

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

yarn berry puede usar el método de importación $> yarn plugin import <name> para extender el complemento (yarnpkg.com/cli/plugin/…), este comando También se actualizará .yarnrc.yml .

# .yarnrc.yml
complementos:
  - ruta: .yarn/plugins/@yarnpkg/plugin-semver-up.cjs
    especificación: "https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js"

Como se menciona en la sección de historial, debido a razones de compatibilidad, Puede haber algunos problemas con las dependencias en el modo estricto de PnP. Existe una solución típica para este tipo de problema PnP: la política de configuración de extensión de paquetes.

# .yarnrc.yml
Extensiones del paquete:
  "componentes-estilo@*":
    dependencias:
      reaccionar-is: "*"

pnpm

pnpm usa el mismo mecanismo de configuración que npm , por lo que puedes usar archivos .npmrc . Configurar un registro privado también funciona igual que usar npm . Los proyectos de paquetes múltiples pueden ser compatibles con la función de espacio de trabajo de pnpm. Para inicializar monorepo , debe especificar la ubicación del paquete en el archivo pnpm-workspace.yaml .

# pnpm-espacio de trabajo.yaml
paquetes:
  - 'paquetes/**'

Monorepo

¿Qué es Monorepo?

(En realidad, aquí hay tres conceptos, almacén único y proyectos múltiples, almacén único y proyecto único, y almacenes múltiples y proyectos múltiples).

monorepo es un repositorio que contiene múltiples proyectos. Estos proyectos se denominan workspace o paquetes. Mantener todo en un solo lugar en lugar de utilizar varios repositorios es una estrategia de organización de proyectos.

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

npm

El equipo npm ha lanzado la tan esperada función de espacio de trabajo de npm en v7. Contiene muchos comandos CLI para ayudar a administrar proyectos de varios paquetes desde el paquete raíz. La mayoría de los comandos se pueden usar con opciones relacionadas con workspace para indicarle npm si debe ejecutarse en un espacio de trabajo específico, en varios o en todos.

# Instalar todas las dependencias para todos los espacios de trabajo
$ npm i --espacios de trabajo.
# correr contra un paquete
$ npm ejecutar prueba --workspace=hooks
# ejecutar contra múltiples paquetes
$ npm ejecutar prueba --workspace=hooks --workspace=utils
# correr contra todos
$ npm ejecutar prueba --espacios de trabajo
#ignorar todos los paquetes que faltan prueba
$ npm run test --workspaces --if-present

consejos: en comparación con otros administradores de paquetes, npm v8 actualmente no admite el filtrado avanzado ni la ejecución paralela de múltiples comandos relacionados con el espacio de trabajo.

hilo

En agosto de 2017, el equipo Yarn anunció la compatibilidad monorepo para la funcionalidad del espacio de trabajo. Anteriormente, los administradores de paquetes solo podían usarse en proyectos de múltiples paquetes con software de terceros como Lerna. Esta nueva incorporación a Yarn también allana el camino para que otros administradores de paquetes implementen dicha funcionalidad.

Si está interesado, puede consultar cómo utilizar la función de espacio de trabajo de Yarn Classic con y sin Lerna. Pero este artículo solo presentará algunos comandos necesarios para ayudarlo a administrar las dependencias en la configuración Yarn Classic .

# Instalar todas las dependencias $yarn para todos los espacios de trabajo 
# Mostrar árbol de dependencia $ información de espacios de trabajo de hilo 
# Ejecute otro paquete para iniciar $ Yarn Workspace Awesome - inicio del paquete
  # Agregar paquete web al paquete $ hilo espacio de trabajo impresionante - agregar paquete - D paquete web
  # agregar React para todos los paquetes $ hilo agregar reaccionar -W

hilo baya

Yarn Berry ha presentado espacios de trabajo desde el principio, ya que su implementación se basa en los conceptos de Yarn Classic . En un comentario de Reddit, el desarrollador principal de Yarn Berry brindó una breve descripción de las características orientadas al espacio de trabajo, que incluyen:

• $ Yarn Add --interactive: puede reutilizar versiones de otros espacios de trabajo al instalar paquetes
• $ Yarn Up: actualiza todos los espacios de trabajo Paquete
• $yarn Workspaces Focus: Instale dependencias para un solo espacio de trabajo
• $yarn workspaces foreach: ejecute el comando en todos los espacios de trabajo

Yarn Berry usa una serie de protocolos que se pueden usar en dependencies o devDependencies del archivo package.json . Entre ellos se encuentra el protocolo workspace .

A diferencia del espacio de trabajo de Yarn Classic , Yarn Berry define claramente que una dependencia debe ser uno de los paquetes en este monorepo . De lo contrario, si las versiones no coinciden, Yarn Berry puede intentar obtener su versión del registro remoto.

{
  //...
  "dependencias": {
    "@doppelmutzi/hooks": "espacio de trabajo:*",
    "servidor http": "14.0.0",
    //...
  }  
}

pnpm

A través del protocolo workspace , pnpm ha contribuido a un proyecto monorepo similar a Yarn Berry . Muchos comandos pnpm aceptan opciones --recursive (-r) o --filter que son particularmente útiles en monorepo . Sus comandos de filtrado nativos también son un gran complemento para Lerna .

# podar todos los espacios de trabajo  
pnpm -r exec -- rm -rf node_modules && rm pnpm-lock.yaml  
# ejecutar todas las pruebas para todos los espacios de trabajo con alcance @doppelmutzi
Prueba de ejecución recursiva pnpm --filter @doppelmutzi/`

Rendimiento y eficiencia del disco

El rendimiento es una parte clave de la decisión de selección. Esta sección presenta puntos de referencia basados ​​en un proyecto pequeño y mediano. Aquí hay algunas notas sobre el proyecto de muestra:

• Ninguno de los conjuntos de puntos de referencia utiliza la función de espacio de trabajo.
• Los proyectos pequeños especifican 33 dependencias.
• Los proyectos medianos especifican 44 dependencias.

Medí cada una de las variantes de nuestro administrador de paquetes una vez usando tres casos de uso (UC). Para una evaluación y explicación detallada, consulte los resultados del Proyecto 1 (P1) y el Proyecto 2 (P2).

• UC 1: sin caché/almacenamiento, sin archivo de bloqueo, sin node_modules o .pnp.cjs
• UC 2: caché/almacenamiento presente, sin archivo de bloqueo, sin node_modules o .pnp.cjs
• UC 3: caché/almacenamiento presente, archivo de bloqueo presente, Sin node_modules o .pnp.cjs

utilicé la herramienta gnomon para medir el tiempo consumido por la instalación ( yarn | gnomon ). Además, medí el tamaño de los archivos generados $ du -sh node_modules .

seguro

mpn

npm es demasiado indulgente cuando se trata de manejar paquetes defectuosos y ha encontrado algunas vulnerabilidades de seguridad que afectaron directamente a muchos proyectos. Por ejemplo, en la versión 5.7.0, cuando ejecuta el comando sudo npm en un sistema operativo Linux, puede cambiar la propiedad de los archivos del sistema, lo que deja el sistema operativo inutilizable.

Otro incidente ocurrió en 2018 relacionado con el robo de Bitcoins. El paquete Node.js EventStream agregó una dependencia maliciosa en su versión 3.3.6. Este paquete malicioso contiene un método criptográfico que intenta robar Bitcoins de la máquina del desarrollador.

Para ayudar a resolver estos problemas, las nuevas versiones npm utilizan algoritmos criptográficos para verificar la integridad de los paquetes instalados. SHA-512.

Yarn

Yarn Classic y Yarn Berry utilizan sumas de verificación para verificar la integridad de cada paquete desde el principio. Yarn también intenta evitar que recupere paquetes maliciosos que no están declarados en package.json : si se encuentra una discrepancia, se cancela la instalación.

Yarn Berry en modo PnP no tiene los problemas de seguridad del método tradicional node_modules . En comparación con Yarn Classic , Yarn Berry mejora la seguridad de la ejecución de comandos. Solo puede ejecutar paquetes que hayan sido declarados en package.json . Esta característica de seguridad es similar a pnpm , que describo a continuación.

pnpm

pnpm todavía usa sumas de verificación para verificar la integridad de cada paquete instalado antes de ejecutar su código.

Como mencionamos anteriormente, tanto npm como Yarn Classic tienen problemas de seguridad debido a la promoción. pnpm evita esta situación porque su modelo de gestión no utiliza elevación, sino que genera carpetas node_modules anidadas, eliminando así el riesgo de acceso ilegal a dependencias. Esto significa que las dependencias se declaran en .package.json .

Como comentamos, esto es especialmente importante en un entorno monorepo , ya que la mejora de los algoritmos a veces puede conducir a un no determinismo de dependencia.

Uso de proyectos populares

en conclusión

De hecho, existen grandes diferencias en los principios de los diferentes administradores de paquetes.

pnpm inicialmente se parece a npm , ya que su uso de CLI es pnpm , pero la gestión de dependencias es muy diferente; Yarn Classic sigue siendo popular, pero se considera que el software heredado y el soporte se pueden eliminar en el futuro cercano. Yarn Berry PnP es nuevo, pero su potencial para revolucionar el mundo del administrador de paquetes una vez más aún no se ha realizado.

A lo largo de los años, muchos usuarios han preguntado quién usa qué gerentes de paquetes, y las personas en general parecen estar particularmente interesadas en la madurez y la adopción de Yarn Berry PnP .

El propósito de este artículo es proporcionarle múltiples perspectivas para decidir qué administrador de paquetes usar para usted. Me gustaría señalar que no recomiendo un administrador de paquetes específico. Depende de cómo sopese los diferentes requisitos, por lo que aún puede elegir lo que quiera.

Dirección original en inglés: https://blog.logrocket.com/javascript-package-managers-compared/