Si eres un desarrollador   , entonces estás familiarizado con   y   . Es posible que incluso tengas una opinión firme sobre el uso de uno en lugar del otro. Durante años, los desarrolladores han tenido problemas con la sobrecarga (en el almacenamiento en disco y el tiempo de compilación) al trabajar con los administradores de paquetes de Node.js,   .  de Node.js npm Yarn especialmente npm  Luego llegó   , un administrador de paquetes que maneja el almacenamiento de paquetes de manera diferente, ahorrando espacio a los usuarios y reduciendo el tiempo de compilación. Así es   : pnpm como pnpm describe la diferencia   “Cuando instalas un paquete, lo guardamos en un almacén global en tu máquina y luego creamos un enlace físico desde él en lugar de copiarlo. Para cada versión de un módulo, solo se guarda una copia en el disco. Al usar npm o yarn, por ejemplo, si tienes 100 paquetes que usan lodash, tendrás 100 copias de lodash en el disco. ¡pnpm te permite ahorrar gigabytes de espacio en disco!”  No es de extrañar que pnpm esté ganando terreno, ya que cada vez más desarrolladores lo están utilizando como su gestor de paquetes preferido. Junto con esa creciente tasa de adopción, muchos desarrolladores que ejecutan sus aplicaciones en Heroku (como yo) querían que pnpm fuera compatible.  Afortunadamente, pnpm está disponible a través de   , que se distribuye con Node.js. Por lo tanto, a partir de mayo de 2024,   . Corepack pnpm ya está disponible en Heroku  En esta publicación, cubriremos lo que se necesita para comenzar a usar pnpm en Heroku. Además, mostraremos algunos de los beneficios de almacenamiento y tiempo de compilación que se obtienen al usarlo.  Una breve introducción a pnpm  pnpm se creó para resolver el problema de almacenamiento redundante e ineficiencias en el   que existía desde hacía tiempo en el administrador de paquetes Node.js. npm y Yarn copian las dependencias en   de cada proyecto. Por el contrario, pnpm mantiene todos los paquetes de todos los proyectos en un único almacén global y luego crea vínculos físicos a estos paquetes en lugar de copiarlos. ¿Qué significa esto? manejo de dependencias node_modules  Supongamos que tenemos un proyecto Node.js que utiliza   . Naturalmente, el proyecto tendrá una carpeta   , junto con una subcarpeta llamada   , llena de archivos. Para ser exactos,   tiene 639 archivos y otra subcarpeta llamada   , con otros 415 archivos. lodash node_modules lodash lodash@4.17.21 fp  ¡Eso son más de mil archivos solo para   ! lodash  Creé seis proyectos Node.js: dos con pnpm, dos con npm y dos con Yarn. Cada uno de ellos usa   . Echemos un vistazo a la información de solo uno de los archivos en la carpeta de dependencias   . lodash lodash   ~/six-projects$ ls -i npm-foo/node_modules/lodash/lodash.js 14754214 -rw-rw-r-- 544098 npm-foo/node_modules/lodash/lodash.js ~/six-projects$ ls -i npm-bar/node_modules/lodash/lodash.js 14757384 -rw-rw-r-- 544098 npm-bar/node_modules/lodash/lodash.js ~/six-projects$ ls -i yarn-foo/node_modules/lodash/lodash.js 14760047 -rw-r--r-- 544098 yarn-foo/node_modules/lodash/lodash.js ~/six-projects$ ls -i yarn-bar/node_modules/lodash/lodash.js 14762739 -rw-r--r-- 544098 yarn-bar/node_modules/lodash/lodash.js ~/six-projects$ ls -i pnpm-foo/node_modules/lodash/lodash.js 15922696 -rw-rw-r-- 544098 pnpm-foo/node_modules/lodash/lodash.js ~/six-projects$ ls -i pnpm-bar/node_modules/lodash/lodash.js 15922696 -rw-rw-r-- 544098 pnpm-bar/node_modules/lodash/lodash.js  El archivo   tiene un tamaño de poco más de medio megabyte. No vemos enlaces simbólicos, por lo que, a primera vista, parece que cada proyecto tiene su propia copia de este archivo. Sin embargo, en realidad no es así. lodash.js  Usé   con el indicador   para mostrar el   del archivo   . Puedes ver en los proyectos   y   que ambos archivos tienen el mismo inodo (   ). ¡Están apuntando al mismo archivo! Ese no es el caso de npm o Yarn. ls -i inodo lodash.js pnpm-foo pnpm-bar 15922696  Por lo tanto, si tienes una docena de proyectos que usan npm o Yarn, y esos proyectos usan   , entonces tendrás una docena de copias diferentes de   , junto con copias de otras dependencias en esos proyectos que usan   . En pnpm, cada proyecto y dependencia que requiere esta versión específica de   apunta a la misma copia única y global. lodash lodash lodash lodash  El código de   tiene un tamaño de poco menos de 5 MB. ¿Preferirías tener 100 copias redundantes en tu máquina o solo una copia global? lodash@4.17.21  Al final del día, la instalación de dependencias con pnpm es significativamente más rápida, ya que requiere menos espacio en disco y menos recursos. Para los desarrolladores que trabajan en varios proyectos o que administran dependencias en plataformas en la nube, pnpm ofrece una forma más ágil y rápida de administrar paquetes. Esto hace que pnpm sea ideal para un entorno de implementación optimizado como Heroku.  ¿Estás listo para comenzar a usarlo? Veamos cómo.  Introducción a pnpm  Aquí está la versión de Node.js con la que estamos trabajando en nuestra máquina:   $ node --version v20.18.0  Habilitar y utilizar pnpm  Como mencionamos anteriormente, Corepack viene con Node.js, por lo que simplemente necesitamos usar   para habilitar y usar pnpm. Creamos una carpeta para nuestro proyecto. Luego, ejecutamos estos comandos: corepack   ~/project-pnpm$ corepack enable pnpm ~/project-pnpm$ corepack use pnpm@latest Installing pnpm@9.12.2 in the project... Already up to date Done in 494ms  Esto genera un archivo   que se ve así: package.json   { "packageManager": "pnpm@9.12.2+sha512.22721b3a11f81661ae1ec68ce1a7b879425a1ca5b991c975b074ac220b187ce56c708fe5db69f4c962c989452eee76c82877f4ee80f474cebd61ee13461b6228" }  Esto también genera un archivo   . pnpm-lock.yaml  A continuación, agregamos dependencias a nuestro proyecto. Para fines de demostración, copiamos la lista de   y   que se encuentra en este archivo       . Ahora, nuestro archivo   se ve así: dependencies devDependencies package.json de evaluación comparativa en GitHub package.json   { "version": "0.0.1", "dependencies": { "animate.less": "^2.2.0", "autoprefixer": "^10.4.17", "babel-core": "^6.26.3", "babel-eslint": "^10.1.0", ... "webpack-split-by-path": "^2.0.0", "whatwg-fetch": "^3.6.20" }, "devDependencies": { "nan-as": "^1.6.1" }, "packageManager": "pnpm@9.12.2+sha512.22721b3a11f81661ae1ec68ce1a7b879425a1ca5b991c975b074ac220b187ce56c708fe5db69f4c962c989452eee76c82877f4ee80f474cebd61ee13461b6228" }  Luego instalamos los paquetes.   ~/project-pnpm$ pnpm install  Comparación de comandos comunes  El uso de pnpm es bastante similar al de npm o yarn, por lo que debería resultar intuitivo. A continuación, se incluye una tabla que compara los diferentes usos de los comandos más comunes (extraída de   ).  esta publicación  Comparación de la velocidad de compilación de Heroku  Ahora que hemos mostrado cómo poner en marcha un proyecto con pnpm (es bastante sencillo, ¿verdad?), queríamos comparar los tiempos de compilación de diferentes administradores de paquetes cuando se ejecutan en Heroku. Configuramos tres proyectos con dependencias idénticas: usando npm, Yarn y pnpm.  Primero, iniciamos sesión en la CLI de Heroku (   ). heroku login  Luego, creamos una aplicación para un proyecto. Mostraremos los pasos para el proyecto npm.   ~/project-npm$ heroku apps:create --stack heroku-24 npm-timing Creating ⬢ npm-timing... done, stack is heroku-24 https://npm-timing-5d4e30a1c656.herokuapp.com/ | https://git.heroku.com/npm-timing.git  Encontramos un   a los pasos de compilación en el registro de Heroku para que podamos calcular los tiempos de compilación reales de nuestros proyectos. Queremos agregar ese paquete de compilación a nuestro proyecto y ejecutarlo antes del   Lo hacemos con los siguientes dos comandos: paquete de compilación que agrega marcas de tiempo paquete de compilación estándar para Node.js.   ~/project-npm$ heroku buildpacks:add \ --index=1 \ https://github.com/edmorley/heroku-buildpack-timestamps.git \ --app pnpm-timing ~/project-npm$ heroku buildpacks:add \ --index=2 heroku/nodejs \ --app npm-timing Buildpack added. Next release on npm-timing will use: 1. https://github.com/edmorley/heroku-buildpack-timestamps.git 2. heroku/nodejs Run git push heroku main to create a new release using these buildpacks.  ¡Eso es todo! Luego, enviamos el código para nuestro proyecto administrado por npm.   ~/project-npm$ git push heroku main ... remote: Updated 4 paths from 5af8e67 remote: Compressing source files... done. remote: Building source: remote: remote: -----> Building on the Heroku-24 stack remote: -----> Using buildpacks: remote: 1. https://github.com/edmorley/heroku-buildpack-timestamps.git remote: 2. heroku/nodejs remote: -----> Timestamp app detected remote: -----> Node.js app detected ... remote: 2024-10-22 22:31:29 -----> Installing dependencies remote: 2024-10-22 22:31:29 Installing node modules remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 added 1435 packages, and audited 1436 packages in 11s remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 184 packages are looking for funding remote: 2024-10-22 22:31:41 run `npm fund` for details remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 96 vulnerabilities (1 low, 38 moderate, 21 high, 36 critical) remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 To address issues that do not require attention, run: remote: 2024-10-22 22:31:41 npm audit fix remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 To address all issues possible (including breaking changes), run: remote: 2024-10-22 22:31:41 npm audit fix --force remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 Some issues need review, and may require choosing remote: 2024-10-22 22:31:41 a different dependency. remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 Run `npm audit` for details. remote: 2024-10-22 22:31:41 npm notice remote: 2024-10-22 22:31:41 npm notice New minor version of npm available! 10.8.2 -> 10.9.0 remote: 2024-10-22 22:31:41 npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.9.0 remote: 2024-10-22 22:31:41 npm notice To update run: npm install -g npm@10.9.0 remote: 2024-10-22 22:31:41 npm notice remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 -----> Build remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 -----> Caching build remote: 2024-10-22 22:31:41 - npm cache remote: 2024-10-22 22:31:41 remote: 2024-10-22 22:31:41 -----> Pruning devDependencies remote: 2024-10-22 22:31:44 remote: 2024-10-22 22:31:44 up to date, audited 1435 packages in 4s remote: 2024-10-22 22:31:44 remote: 2024-10-22 22:31:44 184 packages are looking for funding remote: 2024-10-22 22:31:44 run `npm fund` for details remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 96 vulnerabilities (1 low, 38 moderate, 21 high, 36 critical) remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 To address issues that do not require attention, run: remote: 2024-10-22 22:31:45 npm audit fix remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 To address all issues possible (including breaking changes), run: remote: 2024-10-22 22:31:45 npm audit fix --force remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 Some issues need review, and may require choosing remote: 2024-10-22 22:31:45 a different dependency. remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 Run `npm audit` for details. remote: 2024-10-22 22:31:45 npm notice remote: 2024-10-22 22:31:45 npm notice New minor version of npm available! 10.8.2 -> 10.9.0 remote: 2024-10-22 22:31:45 npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.9.0 remote: 2024-10-22 22:31:45 npm notice To update run: npm install -g npm@10.9.0 remote: 2024-10-22 22:31:45 npm notice remote: 2024-10-22 22:31:45 remote: 2024-10-22 22:31:45 -----> Build succeeded! ...  Observamos el tiempo de los siguientes pasos, hasta que apareció el mensaje   cerca del final: Build succeeded   Installing dependencies   Build   Pruning devDependencies   Caching build   En total, con npm, esta compilación tardó 16 segundos.  Ejecutamos la misma configuración para el proyecto administrado por pnpm, utilizando también el paquete de compilación de tiempos.   ~/project-pnpm$ heroku apps:create --stack heroku-24 pnpm-timing ~/project-pnpm$ heroku buildpacks:add \ --index=1 \ https://github.com/edmorley/heroku-buildpack-timestamps.git \ --app pnpm-timing ~/project-pnpm$ heroku buildpacks:add \ --index=2 heroku/nodejs \ --app pnpm-timing ~/project-pnpm$ git push heroku main … remote: 2024-10-22 22:38:34 -----> Installing dependencies remote: 2024-10-22 22:38:34 Running 'pnpm install' with pnpm-lock.yaml … remote: 2024-10-22 22:38:49 remote: 2024-10-22 22:38:49 dependencies: remote: 2024-10-22 22:38:49 + animate.less 2.2.0 remote: 2024-10-22 22:38:49 + autoprefixer 10.4.20 remote: 2024-10-22 22:38:49 + babel-core 6.26.3 … remote: 2024-10-22 22:38:51 -----> Build succeeded!   Para la misma compilación con pnpm, tomó solo 7 segundos.  Descubrimos que el ahorro de tiempo no se produce solo en la instalación inicial. Las compilaciones posteriores, que utilizan la caché de dependencias, también son más rápidas con pnpm.   Conclusión  Cuando comencé a   , usé npm. Hace varios años, cambié a Yarn, y eso es lo que había estado usando... hasta hace poco. Ahora, hice el cambio a pnpm. En mi máquina local, puedo liberar espacio de disco sustancial. Las compilaciones también son más rápidas. Y ahora, con el soporte de Heroku para pnpm, esto cierra el ciclo para que pueda usarlo exclusivamente desde el desarrollo local hasta la implementación en la nube. desarrollar Node.js  ¡Feliz codificación!

2022 - HackerNoon Contributor of the Year - Engineering

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Jobs

2022 - HackerNoon Contributor of the Year - Kubernetes

2022 - HackerNoon Contributor of the Year - Npm

2022 - No No No Nodejs

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - No No No Nodejs

Nominated for 2022 - HackerNoon Contributor of the Year - Jobs

Nominated for 2022 - HackerNoon Contributor of the Year - Npm

Nominated for 2022 - HackerNoon Contributor of the Year - Kubernetes

Nominated for 2022 - HackerNoon Contributor of the Year - Engineering

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Vaya, pnpm, eres muy rápido: cómo usarlo en Heroku

Vaya, pnpm, eres muy rápido: cómo usarlo en Heroku

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Una breve introducción a la teoría del cerebro de Boltzmann

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Una breve introducción a la teoría del cerebro de Boltzmann

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps