pnpm: un gestor de paquetes rápido y eficiente para JavaScript

Hola, mi nombre es Zoltan Kochan y hoy voy a hablar sobre pnpm, que es un gestor de paquetes rápido y eficiente en el uso del espacio en disco.

Antes de eso, permítanme presentarme. Soy Zoltan Kochan. Nací y crecí en Ucrania. Actualmente vivo en Ucrania también. Por ahora estoy a salvo. Trabajo de forma remota para BIT. BIT es una empresa que ayuda a los desarrolladores a implementar el desarrollo basado en componentes. Antes de BIT, trabajé para Just Answer durante nueve años y, al mismo tiempo, desde 2016, he estado desarrollando y manteniendo npm-pm constantemente. Antes de hablar sobre npm-pm, hablemos brevemente sobre otros gestores de paquetes de JavaScript. El gestor de paquetes más popular de node.js o JavaScript es npm, que es el gestor de paquetes oficial del registro de npm. Se envía con node.js y en el pasado npm tuvo muchos problemas, como ser lento, no ser determinista, a veces dar resultados extraños, por lo que se crearon algunas alternativas. Una de las alternativas fue creada por Facebook, probablemente hayas oído hablar de yarn, que es el segundo gestor de paquetes más popular después de npm. Ahora es mantenido por la comunidad y resolvió muchos de los problemas que npm tenía en las versiones 3 y 4. Desde entonces, en la versión 2, yarn ha cambiado para usar plug and play de forma predeterminada, por lo que aunque admite la instalación clásica de módulos de nodo, ahora prefiere usar plug and play, lo cual a muchos les gusta y a muchos no. Personalmente, creo que es una característica genial. Y yarn se envía actualmente con la última versión de Node.js. El tercer gestor de paquetes más popular es pnpm. Es un proyecto completamente independiente, fue creado por colaboradores de código abierto para solucionar los problemas de npm v3. Al mismo tiempo que yarn 2, por lo que pnpm no es como un proyecto nuevo, existe desde que yarn existe, básicamente. Y ahora es compatible con bit, porque trabajo en bit y pnpm se utiliza mucho en bitcli para la gestión de paquetes y pnpm también se envía con nodjs a través de la función corepack de nodjs. Si comparamos estos gestores de paquetes por popularidad, obviamente npm es actualmente el más popular, luego yarn y pnpm es el menos popular, aunque pnpm salió al mismo tiempo que yarn, pero por supuesto Facebook tenía mucho poder de marketing para hacer que yarn fuera muy popular al principio. Sin embargo, aunque pnpm es menos popular por ahora, tuvo un gran aumento en popularidad el año pasado, por lo que en 2021 se descargó pnpm tres veces más que en 2020. Tenemos muchas grandes empresas de tecnología que ya utilizan pnpm, incluso Microsoft utiliza pnpm en algunos de sus proyectos, y el equipo de frontend de TikTok utiliza pnpm. Así que pnpm funciona muy bien y está listo para producción.

Veamos qué hace que pnpm sea único. Cuando instalas una dependencia con npm o Yarn Classic, todas las subdependencias se elevan a la raíz de los módulos de nodo. Como puedes ver en este ejemplo, aunque solo Express está en las dependencias, todos esos otros paquetes también se elevan a la raíz de los módulos de nodo. Por el contrario, pnpm solo coloca Express en la raíz de los módulos de nodo. Por lo tanto, aunque cookie no es una dependencia de tu proyecto, importarla funcionará. Esta es una situación peligrosa.

Con PMPM, tu código solo tiene acceso a los paquetes que se declaran como dependencias de tu proyecto. ¿Cómo puede PMPM crear una estructura de módulo de nodo aislada?

En este ejemplo, puedes ver que Express es una dependencia directa y KUKI es una dependencia de Express. Como puedes ver, solo Express se coloca en la raíz de la carpeta de nodemodules del proyecto. Y KUKI y en realidad ese Express dentro de nodemodules, es un enlace simbólico, es simplemente un enlace simbólico a una carpeta dentro de la carpeta .pmpm.

Esto funciona porque al buscar dependencias, el algoritmo de resolución de node.js utiliza la ubicación real del paquete como punto de partida para buscar sus dependencias. La ubicación real de Express está dentro de la carpeta .pmpm. Por lo tanto, node.js buscará KUKI en la carpeta de nodemodules dedicada, que se encuentra en .pmpm/express en 4.17.3/nodemodules. Y, por supuesto, puedes ver que KUKI dentro de los nodemodules de Express también es solo un enlace simbólico a una carpeta con la ubicación real de KUKI.

Permíteme mostrarte una demostración rápida. Tengo un proyecto vacío. Ejecuto npm add express. La instalación se ha completado. Veamos qué tenemos aquí. Ignora esto. Esto es algo que elevamos por defecto para solucionar algunos problemas. Pero puedes ver que Express solo se eleva y es un enlace simbólico. La ubicación real de Express está aquí. Y aquí también están todas las demás dependencias directas de Express.

Entonces, puedes ver aquí cookie. Pero cookie en realidad es un enlace simbólico a una carpeta aislada dedicada para el paquete cookie. Puedes verlo aquí. En realidad, cookie está aquí. Y esto es un enlace simbólico. Esto también es un enlace simbólico a esta carpeta del paquete accept. Entonces, esta es la ubicación real de accept. Y estos son las dependencias de accept. Por lo tanto, puedes ver que cada paquete está en su propia carpeta aislada con sus propias dependencias. Volvamos a las diapositivas.

QNPM también tiene un soporte muy bueno de Monorepo, gracias a su estructura de módulo de nodo superior. La estructura de directorio de los módulos de nodo elevados es aún peor en un Monorepo. Esto se debe a que en un Monorepo, cuando se utiliza la estructura de módulo de nodo elevado, todas las dependencias de todos los proyectos se elevan a la raíz del Monorepo. Por lo tanto, los proyectos tienen acceso incluso a las dependencias de otros proyectos. Entonces, en este ejemplo, hay un Monorepo con dos proyectos, de viento bar. Foo tiene una dependencia, que es foo. Como puedes ver en su archivo packages.sam. Y bar también tiene una dependencia, que es bar. Si se utiliza un Monorepo elevado, ambas dependencias se elevan a la raíz del Monorepo. Entonces, foo tiene acceso a la dependencia de bar, y bar tiene acceso a la dependencia de foo. Si accidentalmente requieres la profundidad de bar en foo, este código funcionará localmente. Sin embargo, foo se romperá cuando se instale como una dependencia fuera del Monorepo. Esto es aún peor que en un escenario de proyecto único. Porque en un escenario de proyecto único podría romperse en el futuro, pero en este caso se romperá después del primer lanzamiento del paquete. Con la estructura de módulo aislado de pnpm, los proyectos solo tienen acceso a sus propias dependencias. En un Monorepo, pnpm crea una única carpeta .pnpm en la raíz del Monorepo y los proyectos del espacio de trabajo solo enlazan sus dependencias directas. Entonces, tanto foo como bar solo tienen acceso a sus propias dependencias.

Es posible que te preguntes por qué npm no utiliza el mismo enfoque. Bueno, en realidad lo hará, porque están trabajando en una configuración para admitir un directorio de módulos con estilo pnpm. Pero la razón por la que no lo utilizan como predeterminado es porque algunas herramientas aún no admiten enlaces simbólicos, como por ejemplo reactmetio, y muchos paquetes en el ecosistema están básicamente rotos debido a esta arquitectura de módulos elevados. Y dependen de dependencias no declaradas. Pero pnpm realmente tiene una solución para estos casos, porque pnpm también puede crear módulos clásicos sin usar enlaces simbólicos, y con elevación clásica, solo configura la configuración del enlace de nodos en elevado. Y tienes una solución alternativa.

pnpm también resuelve el problema del uso del espacio en disco. Si tienes muchos proyectos de Node.js en tu computadora, es posible que hayas notado que los módulos consumen mucho espacio en disco. pnpm resuelve este problema mediante el uso de un almacenamiento direccionable por contenido. Un almacenamiento direccionable por contenido es básicamente un almacenamiento que guarda archivos mediante un código hash que se calcula a partir del contenido del archivo. Por lo tanto, puedes ver en este ejemplo que en realidad hay un archivo de código en diferentes versiones del mismo paquete, pero aunque sean diferentes versiones, el archivo de código es el mismo, no tiene cambios. En este caso, este archivo tendrá el mismo hash en cada paquete por lo que se creará un solo archivo para él en el almacenamiento. Por lo tanto, aunque tengas 3 paquetes, solo guardas este archivo una vez, en un lugar en el disco.

Cada archivo en los módulos de nodo es simplemente un enlace rígido al almacenamiento direccionable por contenido. Solo en sistemas que lo admiten, no se utilizan enlaces rígidos, sino copias y escritura de archivos, probablemente en Linux y Mac. Estos archivos no consumen espacio adicional en disco, solo son referencias a archivos en el almacenamiento. Esto significa que si dos proyectos en tu computadora tienen el mismo archivo en los módulos, en ambos proyectos ese archivo se vinculará desde el mismo lugar en el disco. No tendrás dos copias del mismo paquete. Solo tendrás enlaces rígidos al almacenamiento direccionable por contenido global. Como resultado, las dependencias en nuevos proyectos consumen mucho menos espacio en disco que con npm o Yarn.

Tengo una diapositiva mezclada, no hay problema. ¿Por qué otros gestores de paquetes no admiten el almacenamiento direccionable por contenido? Creo que en la próxima versión lo activarán de forma predeterminada. Hablemos de por qué pnpm es tan rápido. En la mayoría de los casos, pnpm es más rápido que npm y Yarn. Pero, ¿por qué es así? Npm y Yarn instalan dependencias en etapas. En la primera etapa, se resuelven todos los paquetes. Luego, se obtienen todos los paquetes del registro. Y cuando se obtienen todos los paquetes, las dependencias se escriben en los modules de nodo. Por otro lado, pnpm ejecuta las etapas de instalación por separado para cada dependencia. Mientras algunos paquetes aún se están resolviendo, otros ya se están obteniendo. Y más adelante, algunos paquetes se escriben en los modules de nodo, mientras que otros aún se están obteniendo. Esto hace que pnpm sea increíblemente más rápido que otros gestores de paquetes. Entonces, podrías preguntar, ¿por qué otros gestores de paquetes no hacen lo mismo? En realidad, algunas de estas optimizaciones de velocidad solo son posibles gracias a la estructura única de módulos de nodo determinista creada por pnpm dentro de la carpeta .pmpm. Algunas de estas optimizaciones de velocidad son posibles gracias al uso del almacenamiento direccionable por contenido y algunas de las optimizaciones hacen que el código de los gestores de paquetes sea difícil de entender, por lo que es un compromiso. Si eliges hacer estas optimizaciones, será más difícil contribuir a tu gestor de paquetes.

Y la última función de la que quiero hablar es que Pnpm se empaqueta en un ejecutable, por lo que puedes usarlo en tu sistema incluso si no tienes Node.js preinstalado. Y luego puedes usar Pnpm para instalar Node.js y cambiar entre diferentes versiones de Node.js. Básicamente, puedes usar Pnpm en lugar de nvm, nvs o volta.

Entonces, ¿qué gestor de paquetes deberías usar? Depende. Debes conocer cada gestor de paquetes, debes conocer las funciones de Pnpm, Yarn y Npm. Los tres gestores de paquetes son maduros, son utilizados por grandes empresas de tecnología, tienen muchos colaboradores y son confiables. Por lo tanto, realmente necesitas aprender qué funciones ofrecen, y en cada proyecto, probablemente debas elegir el que mejor se adapte a tus necesidades.

Gracias por asistir a mi presentación. Por supuesto, visita el sitio web de Pnpm para obtener más información y sigue la cuenta de Twitter de Pnpmjs, y sígueme en Twitter también. ¡Gracias! Fue bastante interesante. Me encantaron todos los detalles que compartiste. Así que, gracias por eso.

Entonces, hiciste la pregunta ¿cómo se enlazan los archivos del almacenamiento direccionable por contenido a los módulos de Node? Y los resultados están aquí. Así que el 63% dice que se usan symlinks, mientras que el 38% dice hardlinks. ¿Y tú qué dices? Sí, es algo que muchas personas por error piensan que solo usamos symlinks. Pero en realidad usamos tanto symlinks como hardlinks en pnpm. Y específicamente para este propósito, para enlazar archivos del almacenamiento direccionable por contenido, usamos hardlinks. Es importante. Podemos usar hardlinks, podemos copiar archivos o podemos usar copiar y escribir archivos. Pero no podemos usar symlinks para este propósito, porque rompería el algoritmo de resolución de Node.js.

Genial. Así que el 38% de todos ustedes lo acertaron. Son hardlinks. Así que solo para ampliar un poco, tal vez si te gustaría dar una breve diferencia entre symlinks y hardlinks para la audiencia. Sí. Un symlink es básicamente solo una referencia a otro lugar en el disco. Entonces, básicamente, si un módulo de Node está enlazado, Node.js resuelve esta ubicación a la ubicación real del archivo. Entonces, cuando busca las dependencias de este módulo, busca desde la ubicación real del archivo. Un hardlink es diferente. Básicamente, es otro archivo con su propia ubicación.

Puedes tener muchos hardlinks en el disco en diferentes ubicaciones. Para Node.js, son como archivos separados. Estos archivos apuntan a la misma ubicación en el disco físico. Estos archivos no consumen espacio adicional en tu disco.

Genial, eso es útil. Sí, y así es como se hace eficiente la secuencia. Sí, usamos menos espacio en disco. Sí, correcto. Eso es perfecto.

Así que vamos a tomar algunas preguntas de la audiencia. Tenemos una pregunta. ¿Qué tan difícil es migrar la base de código de YARN a pnpm, por ejemplo? Es... Si es solo un repositorio de paquetes, entonces es realmente fácil. Hay un comando de importación. Así que solo tienes que ejecutar pnpm import y convertirá tu archivo de registro de YARN a un archivo de registro YAML de pnpm, y solo necesitas eliminar el archivo de YARN y confirmar el nuevo archivo de registro. Luego, tal vez actualices tus scripts de CI de YARN install a pnpm install, de YARN run a pnpm run. En la mayoría de los casos, todo lo que necesitas hacer es cambiar YARN por pnpm y funcionará como un reemplazo directo. Para un espacio de trabajo, necesitas cambiar cómo enumeras los paquetes globales. YARN usa un campo en el package.json y pnpm usa un archivo separado, pnpm-workspace.

¿Cuál es el significado completo de pnpm? ¿Qué representa? Este nombre fue inventado antes que yo. El primer mantenedor de pnpm fue Rico Stacrus de Filipinas. Significa simplemente npm de rendimiento. La primera versión era 10 veces más rápida que npm en ese momento. Eso es increíble.

Quería hacer una pregunta. ¿Cómo funciona pnpm en computadoras que pueden tener múltiples discos o sistemas de archivos múltiples? ¿Cómo funciona todo en eso? La desventaja de los hardlinks es que un hardlink solo puede estar en el ámbito de un disco. Entonces no puedes tener tu almacenamiento direccionable por contenido en el disco C y tu proyecto en el disco D, si estás usando Windows, por ejemplo. En ese caso, pnpm crea un almacenamiento separado para cada disco. Entonces, si tienes proyectos en el disco C, tendrás un almacenamiento para esos proyectos en el proyecto C y si tienes un proyecto en el disco D, tendrás un almacenamiento separado para esos proyectos. O alternativamente, puedes usar un almacenamiento, pero si el almacenamiento está en el disco C, entonces en el disco C se usarán hardlinks a ese almacenamiento, pero en el disco D, los archivos se copiarán. Entonces no obtendrás los beneficios de la eficiencia del espacio en disco. Eso es interesante, sí. Gracias por esta respuesta. No veo más preguntas, pero para la audiencia, si aún tienen más preguntas, siempre pueden hacerlas en el canal de preguntas y respuestas y obtendrán las respuestas de Zoltan allí. Y no tenemos ninguna sala de oradores para Zoltan, así que asegúrate de hacer las preguntas en el canal de preguntas y respuestas. Gracias una vez más, Zoltan, por unirte a nosotros hoy para esta magnífica charla y también por responder estas buenas preguntas. Muchas gracias. Gracias. Gracias por tenerme.