pnpm – un Gestor de Paquetes Rápido y Eficiente en Espacio de Disco 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 también vivo en Ucrania. 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 mientras tanto, desde 2016, estoy constantemente desarrollando y manteniendo npm-pm.

Antes de hablar sobre npm-pm, hablemos brevemente sobre otros gestores de paquetes de Javascript. El gestor de paquetes de node.js o javascript más popular es npm, que es el gestor de paquetes oficial del registro de npm. Se distribuye con node.js y en el pasado npm tuvo muchos problemas, como que era lento, era indeterminista, a veces daba resultados graciosos, 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 la versión 3 y 4. Desde entonces, en v2, yarn ha cambiado para usar plug and play por defecto, así que aunque sí admite la instalación clásica de módulos de nodo, ahora prefiere usar el plug and play, que a muchos les encanta y a muchos les disgusta. Personalmente, creo que es una característica genial. Y yarn se distribuye 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, así que pnpm no es como un proyecto nuevo, existe desde que existe yarn, básicamente. Y ahora es compatible con bit, porque trabajo en bit y pnpm se usa mucho en el bitcli para la gestión de paquetes y pnpm también se distribuye 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 de popularidad el año pasado, así que en 2021 pnpm se descargó tres veces más que en 2020. Tenemos muchas grandes empresas tecnológicas que ya usan pnpm, así que incluso Microsoft usa pnpm en algunos de sus proyectos, y el equipo de frontend de TikTok usa pnpm. Así que pnpm funciona muy bien, y está listo para producción, sin duda. Veamos qué hace único a pnpm.

Cuando instalas una dependencia con npm o Yarn Classic, todas las sub-dependencias son elevadas 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. Así que aunque cookie no es una dependencia de tu proyecto, importarlo funcionará. Esta es una situación peligrosa.

Pero, ¿qué pasará si sale una nueva versión de Express y cookie ya no está en sus dependencias? Tu paquete se romperá. PMPM previene tales errores.

Con PMPM tu código solo tiene acceso a los paquetes que están declarados como dependencias de tu proyecto. ¿Cómo es que PMPM puede crear una estructura de módulo de nodo tan aislada?

En este ejemplo, ves 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 módulos de nodo del proyecto. Y KUKI y en realidad ese Express dentro de los módulos de nodo, es un seamlink, es solo un seamlink 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. Así que nodejs buscará KUKI en la carpeta nodemodules dedicada que está 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 symlink a una carpeta con la ubicación real de KUKI.

Así que déjame mostrarte una demostración rápida. Tengo un proyecto vacío. Ejecuto npm add express. La instalación está completada. Veamos qué tenemos aquí. Ignora esto. Esto es algo que elevamos por defecto para solucionar algunos problemas. Pero puedes ver que Express solo está elevado y es un Syn-Link. La ubicación real de Express está aquí. Y aquí están en esta carpeta también todas las otras dependencias directas de Express.

Así que puedes ver aquí cookie. Pero cookie es en realidad un symlink a una carpeta aislada dedicada para el dispositivo cookie. Puedes ver aquí. En realidad, cookie está aquí. Y esto es un symlink. Esto también es un symlink a esta carpeta del paquete accept. Así que esta es la ubicación real de accept. Y estas son las dependencias de accept. Así que puedes ver que cada paquete está en su propia carpeta aislada con sus propias dependencias. Regresemos a las diapositivas.

QNPM también tiene un soporte muy, muy bueno para monorepos, gracias a su estructura superior de módulos de nodo. La estructura del directorio de módulos de nodo elevados es aún peor en un monorepo. Porque en un monorepo, cuando se utiliza un diseño de módulos de nodo elevados, 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. Así que en este ejemplo, hay un monorepo con dos proyectos, de wind 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. Así que 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ódulos aislados de pnpm, los proyectos tienen acceso solo a sus propias dependencias.

Podrías preguntarte por qué npm no está usando el mismo enfoque. Bueno, en realidad lo hará, porque están trabajando en una configuración para soportar un directorio de módulos mod al estilo de pnpm. Pero la razón por la que no lo usan como predeterminado es porque algunas herramientas aún no soportan symlinks, como por ejemplo reactmetio, y muchos paquetes, también muchos paquetes en el ecosistema están básicamente rotos debido a esta arquitectura de hoistedmodmodules. Y dependen de dependencias no declaradas. Pero pnpm en realidad tiene una solución para estos casos, porque pnpm es capaz de crear también un modmodules clásico sin usar symlinks, y con hoisting clásico, solo establece la configuración de nodelinker a hoisted. Y tienes una solución alternativa.

pnpm también soluciona el problema del uso del espacio en disco. Si tienes muchos proyectos de Node.js en tu computadora, habrás notado que modmodules consume mucho de tu espacio en disco. pnpm soluciona este problema utilizando 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. Así que 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 almacén. Así que aunque tengas 3 paquetes, guardas este archivo solo una vez, en un solo lugar en el disco.

Cada archivo en node modules es solo un enlace físico al almacenamiento direccionable por contenido. Solo en sistemas que lo soportan no se usan enlaces físicos sino archivos de copia y escritura, probablemente en Linux y Mac. Estos archivos no consumen espacio adicional en disco, son solo referencias a archivos en el almacén. Esto significa que si dos proyectos en tu computadora tienen el mismo archivo en modmodels, en ambos proyectos ese archivo estará enlazado desde el mismo lugar en el disco. No tendrás dos copias del mismo paquete. Solo tendrás enlaces físicos al almacén global direccionable por contenido. 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 soportan el almacenamiento direccionable por contenido? Creo que en la próxima versión lo activarán por defecto. Hablemos de por qué pmpm es tan rápido. En la mayoría de los casos, pmpm 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, todos los paquetes se obtienen del registro. Y cuando todos los paquetes se han obtenido, las dependencias se escriben en node modules. Por otro lado, pmpm ejecuta las etapas de instalación por separado para cada dependencia. Así que mientras algunos paquetes aún se están resolviendo, otros ya se están obteniendo. Y más tarde, algunos paquetes se escriben en node modules, mientras que otros aún se están obteniendo. Esto hace que pmpm 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 son posibles solo gracias a la estructura única de módulos de nodo determinista creada por pmpm 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 característica de la que creo que quiero hablar es la Pnpm está empaquetado en un ejecutable, por lo que puedes usarlo en tu sistema incluso si no tiene 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. Deberías conocer cada gestor de paquetes, deberías conocer las características de Pnpm, Yarn y Npm. Los tres gestores de paquetes son maduros, son utilizados por grandes empresas tecnológicas, tienen muchos colaboradores y son confiables. Así que realmente necesitas aprender qué características ofrecen, y en cada proyecto, probablemente, deberías 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! Eso 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 almacén direccionable por contenido a los módulos de Node? Y los resultados están. Así que, el 63% dice usando symlinks, mientras que el 38% dice hardlinks. Entonces, ¿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 almacén direccionable por contenido, usamos hardlinks. Es importante. Podemos usar hardlinks, podemos copiar archivos o podemos usar archivos de copia y escritura. 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 ustedes lo acertó. Son hardlinks. Así que solo para expandir un poco sobre esto, tal vez si quisieras dar una breve diferencia entre symlinks y hardlinks para la audiencia. Sí. Así que un symlink es básicamente solo una referencia a otro lugar en el disco. Así que básicamente, si un módulo de Node está symlinkeado, Node.js resuelve esta ubicación a la ubicación real del archivo. Así que cuando está buscando las dependencias de este módulo, está buscando desde la ubicación real del archivo. Un hardlink es diferente. Es básicamente otro archivo con su propia ubicación.

Puedes tener muchos hardlinks en el disco en diferentes lugares. Para Node.js, es 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 haces la secuencia eficiente. Sí, usamos menos espacio en disco. Sí, correcto. Eso es perfecto.

Así que tomemos algunas preguntas de la audiencia. Entonces, 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 un solo paquete, entonces es realmente fácil. Hay un comando de importación. Así que solo puedes 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 simplemente cambiar YARN a pnpm y funcionará como un reemplazo directo. Para un workspace, necesitas cambiar cómo listas los globs de paquetes. YARN usa un campo en package.json y pnpm usa un archivo separado, pnpm-workspace.yarn.

¿Cuál es la forma completa de pnpm? ¿Qué significa? Este nombre fue inventado antes que yo. El primer mantenedor de pnpm fue Rico Stacrus de Filipinas. Es simplemente performance npm. La primera versión fue 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 podrían tener múltiples discos o múltiples sistemas de archivos? ¿Cómo funciona todo eso? La desventaja de los hardlinks es que un hardlink solo puede estar en el ámbito de un disco. Así que no puedes tener tu almacén ContentAddressable en el disco C y tu proyecto en el disco D, si estás usando Windows, por ejemplo. Así que en ese caso, PNPM crea un almacenamiento separado para cada disco. Así que si tienes proyectos en el disco C, tendrás un almacén para esos proyectos en el proyecto C y si tienes el proyecto D tendrás un almacén separado para esos proyectos. O alternativamente puedes usar un solo almacén pero si el almacén está en el disco C, entonces en el disco C, se usarán hard links para ese almacén, pero en el disco D, los archivos simplemente se copiarán. Así que no tendrás los beneficios de la eficiencia del espacio en disco. Eso es interesante, sí. Gracias por esta respuesta. Así que no veo más preguntas, pero para la audiencia, si todavía 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 charla increíble y también por responder estas buenas preguntas. Muchas gracias. Gracias.