La Vida Secreta de los Gestores de Paquetes

Entonces, estás ejecutando npm install y te vas a tomar una taza de café, y luego vuelves y no tienes idea o tal vez ni te importa lo que npm hizo durante este tiempo.

Entonces, mi nombre es Tali Barak. Trabajo para Youbeek y déjame contarte sobre la vida secreta de los gestores de paquetes. Esto es lo que sucede en tu proyecto, esto es lo básico de npm. Entonces, tienes tu proyecto y necesitas un paquete llamado foo. Entonces, estás ejecutando npm install foo y eso agrega npm install a tu package.json y crea una carpeta node_modules en tu proyecto y coloca el código de foo dentro de ella. Pero, ¿qué pasa si foo requiere buzz? Ok, no hay problema. Creará otra carpeta node_modules debajo de foo y colocará buzz allí. ¿Y si buzz requiere bugs? Bueno, lo mismo. Lo colocará y lo agregará allí. Y ¿qué sucede si tanto foo como bar requieren buzz? En este caso, en la implementación ingenua de npm, tendrás dos paquetes de buzz en el mismo proyecto. Y esto crea toda la estructura de tu sistema de archivos que replica la estructura de paquetes que tienes en tu proyecto. Y esto fue bueno, pero creó algunos problemas. Por ejemplo, hizo que tus node_modules fueran enormes. También creó un problema con las dependencias circulares. Eso significa que si foo necesitaba buzz, que necesitaba buzz, que necesitaba buzz, que necesitaba bar nuevamente, que necesitaba buzz y necesitaba buzz, entrarías en un bucle infinito. Y esto, por cierto, es bastante común. No es tan raro como podrías pensar. Otro problema común es con los singletons. Si necesitas una única instancia de un cierto paquete, como el paquete debug, por ejemplo, en esta estructura tendrías múltiples instancias, y eso puede causar errores cuando ejecutas los paquetes. Y el último ya no está con nosotros. Gracias a Dios por eso. Era un problema de Windows 8 que la ruta del archivo estaba limitada a 256 caracteres. Esto es menos común.

Entonces, ¿qué hizo NPM para resolver eso? Decidieron hacer una deduplicación de los paquetes que estaban duplicados. Entonces, en lugar de tener buzz dos veces, lo colocarían en el nivel más alto posible y lo usarían allí. Y la razón por la que esto funcionó es debido a la forma en que Node requiere los paquetes. Entonces, si buzz necesitaba buzz, iría debajo de la carpeta node_modules de Node y lo buscaría. Si no lo encuentra, subirá un nivel y buscará un tercero.

Y luego, si no lo encuentra, subirá otro nivel. Y ahí está. De hecho, encontró buzz allí y lo usará. A continuación, decidieron, bueno, vamos a llevarlo un paso más allá. Si podemos mover los paquetes hacia arriba en el árbol, ¿por qué solo el duplicado? En realidad, podemos hacer eso para todos los paquetes. Y crearon un árbol muy plano con todos los paquetes. Y esto fue bueno. Esto resolvió el problema. Ahora tenías paquetes más pequeños, rutas más cortas porque no iba tan profundo. Era solo unidireccional, sin circulares. Hacía que cada paquete fuera único.

Era bueno, pero luego tuvimos un problema. Cada paquete podría tener una versión diferente que requiere. Entonces, tu árbol, el árbol que necesitas, en realidad no se ve como este. Tienes diferentes versiones de los mismos paquetes requeridos en diferentes lugares del árbol. Y aún peor, en algunos casos, las versiones podrían entrar en conflicto. Eso significa que tu foo podría requerir buzz en la versión uno, pero bar requiere buzz en la versión dos. ¿Y cómo lo aplanas? ¿Qué pones en el nivel superior? De hecho, tenemos un problema aquí, tu estructura de archivos, tu estructura de paquetes, ya no es un árbol. En realidad, es un grafo. Y la forma en que se resolvió es que diferentes versiones de NPM tenían diferentes soluciones. A veces tomaría una popular. A veces tomaría la primera y la colocaría en la parte superior del árbol. Mientras que la otra versión que se requería se dejaba debajo del paquete que lo requería. Como en este caso aquí, donde podrías promover dos o uno, dependiendo del orden. Y esto es un problema porque ahora obtenemos un árbol muy inestable e impredecible. Y la forma en que NPM y también Yarn en la versión 1 lo resolvieron fue tomando una instantánea de todos tus módulos de nodo. Y este es el famoso archivo de registro. NPM lo tiene como un archivo shrink wrap. Y luego Yarn agregó el archivo de registro de Yarn. Y esta es la forma en que NPM se asegura de que la estructura de paquetes y los archivos de módulos de nodo en un proyecto sean los mismos que los de

Entonces esta es una solución que se utilizó y la otra solución es la que yarn2, que tiene el nombre en clave berry, introdujo. Básicamente dicen que ellos son el gestor de paquetes y saben exactamente qué paquete es requerido por cada paquete. Tienen un mapa de todos los modules de nodo y todos los paquetes y lo que requieren. Y parchean, cambian la forma en que Node solicita los archivos. Entonces, si Node ahora requiere un paquete, ya no irá directamente al sistema de archivos y obtendrá el paquete, sino que accederá a yarn y solicitará el paquete específico que necesita y yarn buscará en este mapa de modules y devolverá el archivo exacto que muestra eso.

Así que eso fue un vistazo muy, muy breve y rápido a la vida secreta del gestor de paquetes. ¡Muchas gracias! tú