Lo que está realmente mal con node_modules y por qué es tu culpa

Nunca estuve realmente preocupado por el tamaño de node_modules : mi pensamiento era que no debería preocuparse demasiado por las herramientas que necesita para hacer el trabajo. Si necesita un martillo de 20 kg para clavar un clavo, simplemente tómelo. La misma historia con node_modules , puede pesar algunos kilobytes o algunos megabytes porque nuestro martillo imaginario viene con un conjunto de uñas pesadas, ¿verdad? Bueno, tal vez, en teoría.

Vamos a soltar esa analogía elegante y mirar ejemplos del mundo real. Examinaré algunas dependencias @ angular / cli, pero solo porque es una biblioteca bastante grande. No quiero que se vea mal, es solo una buena representación de un paquete promedio. Lo instalé en el directorio vacío usando npm@5.5.1. Npm informó que "agregó 976 paquetes en 107.13s" después de la instalación (eso es 141 megabytes en el disco).

De acuerdo, el paquete cli es una biblioteca bastante robusta y su lista de dependencias es demasiado larga, pero tal vez se necesiten todas. Centrémonos en las primeras common-tags paquete seleccionado. Vista rápida de su documentación y puede decir que es una especie de biblioteca de utilidades con varios métodos comunes para trabajar con el texto. Hasta aquí todo bien – métodos generales, fáciles de reutilizar.

Solo una pequeña falla: en los deps de common-tags vemos babel-runtime . Un poco sorprendente, solo necesitamos algunas funciones de texto comunes, pero – hey – es 2017 JS para ti. Oh, espera, resulta que quiere core-js y regenerator-runtime . Afortunadamente termina aquí y, lo que es más, core-js también es biblioteca de utilidades, bastante grande, honestamente. ¡Tiene tantas funciones dentro que apuesto a que muchos otros paquetes lo usarán!

Realmente no. Solo babel-runtime tiene en sus fallas. Oopsie.
Y volviendo al punto de partida, cli usa solo 3 (triviales) métodos de common-tags – stripIndents , stripIndent , oneLine . Oopsie daisy.

Para usar estos 3 métodos node_modules necesita 1826 archivos. Y eso es solo 4 de los mencionados 976 paquetes instalados.

Este es tu sueño sobre el colapso del paquete liviano

La siguiente dependencia es core-object , se descargó en un total de 8 paquetes y 45 archivos, por lo que no es tan malo. Y otros paquetes también usan estos archivos, principalmente chalk .
El verdadero fastidio es que 6 de estos 8 son dependencias de chalk y la chalk se usa solo una vez en core-object para pintar el mensaje de desaprobación amarilla.

Otros hallazgos aleatorios:

• algunos paquetes para abordar el tema de "querystring"
• algunos intentos de afirmar métodos que varían en complejidad desde minimalistic-assert hasta assert-plus
• docenas de varios paquetes is-*
• mucha paquetes para "prettifyfifafiying-whatever" errores e impresiones de la consola
• cientos de polyfills / shims o reimplementación de métodos nativos
• Por supuesto, las lodash anteriores se sientan en node_modules junto a lodash completo
• … y algunos métodos parciales de lodash como deps separados

Y, al azar, me refiero a simplemente seleccionar algunos paquetes y buscar brevemente otros similares, lo que a menudo fue muy fácil porque los paquetes tenían nombres similares.

Algunos de los duplicados encontrados