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
hastaassert-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 ennode_modules
junto alodash
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