¿Alguna vez te has preguntado qué sucede después de ejecutar npm install y vas a tomar un café? Vamos a sumergirnos en el proceso de instalación de Npm y Yarn, y cómo puedes poner este conocimiento en práctica.
Video Summary and Transcription
npm install puede ser un proceso misterioso, pero entender cómo funcionan los gestores de paquetes es esencial. NPM resolvió problemas como los grandes node_modules, las dependencias circulares y las múltiples instancias del mismo paquete. Gestionar las versiones y conflictos de los paquetes es crucial para mantener la consistencia en los proyectos. Enfoques alternativos para la gestión de paquetes, como PNPM y Yarn2, brindan información sobre las complejidades ocultas de los gestores de paquetes.
Available in English
1. The Secret Life of Package Managers
Short description:
npm install puede ser un proceso misterioso, pero entender cómo funcionan los gestores de paquetes es esencial. Cuando instalas un paquete, crea una carpeta node_modules y agrega el código necesario. Sin embargo, esto puede llevar a problemas como node_modules grandes, dependencias circulares y múltiples instancias del mismo paquete. NPM resolvió estos problemas al deduplicar los paquetes y utilizar una estructura jerárquica. Esto garantiza una recuperación eficiente de paquetes y elimina la necesidad de copias redundantes.
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.
2. Managing Package Versions and Conflicts
Short description:
Cuando los paquetes tienen diferentes versiones y surgen conflictos, la estructura de paquetes se convierte en un grafo. NPM y Yarn abordan este problema tomando una instantánea de los módulos de nodo, asegurando la consistencia en los proyectos.
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
3. Alternative Approaches to Package Management
Short description:
PNPM y Yarn2 ofrecen enfoques alternativos para la gestión de paquetes. PNPM mantiene las estructuras de paquetes originales en una caché, utilizando enlaces duros para señalar a las versiones requeridas. Yarn2, con el nombre en clave berry, mantiene un mapa de todos los paquetes y sus dependencias, interceptando las solicitudes de archivos de Node para proporcionar los paquetes requeridos. Estas soluciones brindan información sobre las complejidades ocultas de los gestores de paquetes.
el CI o es el mismo que ejecutan tus colegas. Pero aquí hay otra solución. PNPM está haciendo algo inteligente y diferente. PNPM mantiene las estructuras originales, las estructuras de árbol de las que hablamos, manteniendo todos los paquetes y todas sus versiones. Pero en realidad no instalan los paquetes. Almacenan todos los paquetes y todas las versiones diferentes en una caché. Y luego el modules de nodo apunta al nivel del sistema operativo, utilizando enlaces duros a la caché y almacenando la versión exacta y señalando a la versión correcta donde se requiere.
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ú
