Liam Hurst

Liam Hurst

1567474284

Going beyond NPM: meet Yarn & pnpm

Originally published by https://blog.nicco.io

You might wonder now: why? Why should I bother reading this when NPM works perfectly? Is this just another run to the latest framework? Don’t worry: there are actual reasons you might want to switch.

Speed!!… or the lack of it?

The biggest issue that plagues npm is speed. Unfortunately even with the latest version (6) npm is slow. If you ever had to delete the node_modules folder to do a clean install on a bigger project you will know what I mean. Fans start to spin, laptop gets warm and you can go read an article while npm chews on the dependencies.

Yarn to the rescue

Yarn came along in the early days and you definitely have heard about it wandering across Github. Back in the days (before npm 5 with the package-lock.json) Yarn addressed the issues with consistency by being the first to generate a lockfile (yarn.lock). This file could be checked in and the devs would have a consistent dependencies across multiple machines.

Speed

Yarn is often twice as fast as npm. It’s truly impressive and you need to see it for yourself to believe it. The CLI output is also way more human-friendly.

yarn upgrade-interactive

This is incredible . If you run yarn upgrade-interactive you get an interactive CLI where you can choose what packages to upgrade and which not. It’s a simple thing, but one you cannot live without anymore if tried it once.

yarn why

Similar to the previous command this is a very handy cli goodie. simply run yarn why some-package and yarn will tell you why it was installed, from which dependency it came from, etc.

Lack of npx

Unfortunately Yarn lacks the npx equivalent of npm, which is the only drawback I encountered while using yarn. Other than that yarn is a very fast and a solid alternative to npm.

PNPM: The underdog

I truly love this project so I might be biased. They basically implemented a thought I had a while back: reuse the same packages across your computer. Confused? Let me explain:

Have you ever measured the size of the your node_modules?

du -sh node_modules 
# --> 816M node_modules

What?! 0.8Gb for a react-native project?!

Unfortunately that is a pretty common reality and pnpm aims to solve that.

PNPM links your packages with symlinks. This means that the same version of a package only exists once on your computer. If you ever install the same package twice, it will simply symlinked to your node_modules.

On top of that it’s even faster than yarn.

So perfection is achieved? Let’s all switch to pnpm?

Unfortunately it’s not that easy. If you start a new project you can probably go with pnpm, but with existing projects I had some problems with building my apps. So it’s definitely experimental at best and should not be used without rigorous testing as it might break your app. pnpm also supports npx with pnpx.

As you can see above there is no clear winner. NPM is the most compatible of course but really falls behind in terms of speed. Yarn in my opinion is currently your best bet and fallback to npx your-command when npx is needed.

pnpm is an incredibly cool tool but is not ready yet for production. With react-native I can cause problems, but with the “normal” stacks it works very good. I will use pnpm for my personal projects from now on.

Thanks for reading

If you liked this post, share it with all of your programming buddies!

Follow us on Facebook | Twitter

Further reading

The Complete Node.js Developer Course (3rd Edition)

Angular & NodeJS - The MEAN Stack Guide

NodeJS - The Complete Guide (incl. MVC, REST APIs, GraphQL)

A Beginner’s Guide to npm — the Node Package Manager

Node Package Manager (NPM) Tutorial

Creating your first npm package

npm and the Future of JavaScript

Best JavaScript Frameworks, Libraries and Tools to Use in 2019

#npm #node-js #javascript

What is GEEK

Buddha Community

Going beyond NPM: meet Yarn & pnpm
Fannie  Zemlak

Fannie Zemlak

1599854400

What's new in the go 1.15

Go announced Go 1.15 version on 11 Aug 2020. Highlighted updates and features include Substantial improvements to the Go linker, Improved allocation for small objects at high core counts, X.509 CommonName deprecation, GOPROXY supports skipping proxies that return errors, New embedded tzdata package, Several Core Library improvements and more.

As Go promise for maintaining backward compatibility. After upgrading to the latest Go 1.15 version, almost all existing Golang applications or programs continue to compile and run as older Golang version.

#go #golang #go 1.15 #go features #go improvement #go package #go new features

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ónsobre el nivel del marHilo clásicoBaya de hilopnpm
instalar deps enpackage.jsonnpm install
alias: i,add
yarn installoyarncomo clásicopnpm install
alias:i
actualizar deps en package.jsonacc. severnpm update
alias: up,upgrade
yarn upgradeyarn semver up(a través del complemento )pnpm update
alias:up
actualizar las dependencias package.jsona la últimaN / Ayarn upgrade --latestyarn uppnpm update --latest
alias:-L
actualizar deps acc. severnpm update reactyarn upgrade reactyarn semver up reactpnpm up react
actualizar deps a la últimanpm update react@latestyarn upgrade react --latestyarn up reactpnpm up -L react
actualizar deps de forma interactivaN / Ayarn upgrade-interactiveyarn upgrade-interactive(a través del complemento )$ pnpm up --interactive
alias:-i
agregar dependencias de tiempo de ejecuciónnpm i reactyarn add reactcomo clásicopnpm add react
añadir departamentos de desarrollonpm i -D babel
alias:--save-dev
yarn add -D babel
alias:  --dev
como clásicopnpm add -D babel
alias:--save-dev
agregar deps a package.jsonsin semvernpm i -E react
alias:--save-exact
yarn add -E react
alias:--exact
como clásicopnpm add -E react
alias:--save-exact
desinstalar deps y eliminar depackage.jsonnpm uninstall react
alias: remove, rm, r, un,unlink
yarn remove reactcomo clásicopnpm remove react
alias: rm, un,uninstall
desinstalar deps sin actualización depackage.jsonnpm uninstall 
--no-save
N / AN / AN / 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ónsobre el nivel del marHilo clásicoBaya de hilopnpm
instalar paquetes globalmentenpm i -g ntl
alias:--global
yarn global add ntlN/A ( global eliminado )pnpm add --global ntl
actualizar paquetes globalmentenpm update -g ntlyarn global upgrade ntlN / Apnpm update --global ntl
eliminar paquetes globalmentenpm uninstall -g ntlyarn global remove ntlN / Apnpm remove
--global ntl
ejecutar binarios desde la terminalnpm exec ntlyarn ntlyarn ntlpnpm ntl
ejecutar binarios desde el scriptntlntlntlntl
ejecución de paquetes dinámicosnpx ntlN / Ayarn dlx ntlpnpm dlx ntl
agregar dependencias de tiempo de ejecuciónnpm i reactyarn add reactcomo clásicopnpm add react
añadir departamentos de desarrollonpm i -D babel
alias:--save-dev
yarn add -D babel
alias:--dev
como clásicopnpm add -D babel
alias:--save-dev
agregar deps a package.jsonsin semvernpm i -E react
alias:--save-exact
yarn add -E react
alias:--exact
como clásicopnpm add -E react
alias:--save-exact
desinstalar deps y eliminar depackage.jsonnpm uninstall react
alias: remove, rm, r, un,unlink
yarn remove reactcomo clásicopnpm remove react
alias: rm, un,uninstall
desinstalar deps sin actualización depackage.jsonnpm uninstall
--no-save
N / AN / AN / 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ónsobre el nivel del marHilo clásicoBaya de hilopnpm
publicar paquetenpm publishyarn publishyarn npm publishpnpm publish
lista de unidades instaladasnpm ls
alias: list, la,ll
yarn list pnpm list
alias:ls
lista de dependencias obsoletasnpm outdatedyarn outdatedyarn upgrade-interactivepnpm outdated
imprimir información sobre depsnpm explain ntl
alias:why
yarn why ntlcomo clásicopnpm why ntl
proyecto de inicionpm init -y
npm init(interactivo)
alias:--yes
yarn init -y
yarn init(interactivo)
alias:--yes
yarn initpnpm init -y
pnpm init(interactivo)
alias:--yes
imprimir información de licenciasN/A (a través de un paquete de terceros)yarn licenses listN/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 paquetesN/A (con herramientas de terceros, por ejemplo, nvm)con npm:yarn policies set-version 1.13.0con paquete básico:yarn set version 3.1.1N/A (con npm, Corepack)
realizar auditoria de seguridadnpm audityarn audityarn npm auditpnpm audit
agregar deps a package.jsonsin semvernpm i -E react
alias:--save-exact
yarn add -E react
alias:--exact
como clásicopnpm add -E react
alias:--save-exact
desinstalar deps y eliminar depackage.jsonnpm uninstall react
alias: remove, rm, r, un,unlink
yarn remove reactcomo clásicopnpm remove react
alias: rm, un,uninstall
desinstalar deps sin actualización depackage.jsonnpm uninstall
--no-save
N / AN / AN / 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 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étodonpm
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 186.63s108.89s43.58s31.77s30.13 s56.64s60.91s
CU 241.54s65.49s26.43 s12.46s12,66 s46.36s40.74s
CU 323.59s40.35s20.32s1,61 s1,36 s28.72s31.89s
archivos y tamañopackage-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étodonpm
v8.1.2
Hilo clásico v1.23.0pnpm
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 134.91s43.26s15,6 s13.92s6.44s23.62s20.09s
CU 27.92s33.65s8.86s7.09s5,63 s15.12 s14.93 s
CU 35.09s15.64 s4,73 s0,93 s0,79 s8.18 s6.02s
archivos y tamañopackage-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 marHilo clásicoBaya de hilopnpm
EsbeltoReaccionares (con node_modules)Ver 3
PreactuarAngularLibro de cuentos (con node_modules)lista de navegadores
Express.jsHumanoBabel (con node_modules)Prisma
MeteoritoSiguiente.jsKit de herramientas Redux (con node_modules)SvelteKit
Servidor Apologatsby  
 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 

Liam Hurst

Liam Hurst

1567474284

Going beyond NPM: meet Yarn & pnpm

Originally published by https://blog.nicco.io

You might wonder now: why? Why should I bother reading this when NPM works perfectly? Is this just another run to the latest framework? Don’t worry: there are actual reasons you might want to switch.

Speed!!… or the lack of it?

The biggest issue that plagues npm is speed. Unfortunately even with the latest version (6) npm is slow. If you ever had to delete the node_modules folder to do a clean install on a bigger project you will know what I mean. Fans start to spin, laptop gets warm and you can go read an article while npm chews on the dependencies.

Yarn to the rescue

Yarn came along in the early days and you definitely have heard about it wandering across Github. Back in the days (before npm 5 with the package-lock.json) Yarn addressed the issues with consistency by being the first to generate a lockfile (yarn.lock). This file could be checked in and the devs would have a consistent dependencies across multiple machines.

Speed

Yarn is often twice as fast as npm. It’s truly impressive and you need to see it for yourself to believe it. The CLI output is also way more human-friendly.

yarn upgrade-interactive

This is incredible . If you run yarn upgrade-interactive you get an interactive CLI where you can choose what packages to upgrade and which not. It’s a simple thing, but one you cannot live without anymore if tried it once.

yarn why

Similar to the previous command this is a very handy cli goodie. simply run yarn why some-package and yarn will tell you why it was installed, from which dependency it came from, etc.

Lack of npx

Unfortunately Yarn lacks the npx equivalent of npm, which is the only drawback I encountered while using yarn. Other than that yarn is a very fast and a solid alternative to npm.

PNPM: The underdog

I truly love this project so I might be biased. They basically implemented a thought I had a while back: reuse the same packages across your computer. Confused? Let me explain:

Have you ever measured the size of the your node_modules?

du -sh node_modules 
# --> 816M node_modules

What?! 0.8Gb for a react-native project?!

Unfortunately that is a pretty common reality and pnpm aims to solve that.

PNPM links your packages with symlinks. This means that the same version of a package only exists once on your computer. If you ever install the same package twice, it will simply symlinked to your node_modules.

On top of that it’s even faster than yarn.

So perfection is achieved? Let’s all switch to pnpm?

Unfortunately it’s not that easy. If you start a new project you can probably go with pnpm, but with existing projects I had some problems with building my apps. So it’s definitely experimental at best and should not be used without rigorous testing as it might break your app. pnpm also supports npx with pnpx.

As you can see above there is no clear winner. NPM is the most compatible of course but really falls behind in terms of speed. Yarn in my opinion is currently your best bet and fallback to npx your-command when npx is needed.

pnpm is an incredibly cool tool but is not ready yet for production. With react-native I can cause problems, but with the “normal” stacks it works very good. I will use pnpm for my personal projects from now on.

Thanks for reading

If you liked this post, share it with all of your programming buddies!

Follow us on Facebook | Twitter

Further reading

The Complete Node.js Developer Course (3rd Edition)

Angular & NodeJS - The MEAN Stack Guide

NodeJS - The Complete Guide (incl. MVC, REST APIs, GraphQL)

A Beginner’s Guide to npm — the Node Package Manager

Node Package Manager (NPM) Tutorial

Creating your first npm package

npm and the Future of JavaScript

Best JavaScript Frameworks, Libraries and Tools to Use in 2019

#npm #node-js #javascript

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:

#javascript #npm #node #yarn #developer

Jerel  Mann

Jerel Mann

1594221480

#3: NPM vs Yarn - Mastering NPM

Let’s learn more about NPM and how it works.
All tutorials:
https://https://www.youtube.com/playlist?list=PLYxzS__5yYQmf-iF_9MTZmx7TxnmwnKIk

#npm #yarn #programming