Hay muchos paquetes webpack que encuentran duplicados en el paquete, el más popular de ellos es duplicate-package-checker-webpack-plugin , pero requiere reensamblar el proyecto, y dado que había una tarea para automatizar la selección de la versión óptima de los paquetes, resultó su propia solución alternativa.
Bueno, o mi historia de cómo resultó reducir el paquete en un 15%, en unos segundos.
Como en muchas grandes empresas que tienen una gran base de código, existe una gran cantidad de lógica común, como resultado, utilizamos componentes comunes publicados en nuestro repositorio npm. Se publican a través de lerna , respectivamente, antes de cada instalación o actualización de componentes comunes, surge la pregunta de qué versión instalar. lerna anula todos los componentes que usan el componente publicado (si la versión era anteriormente la última). En consecuencia, siempre hay versiones de varios componentes que se adaptan mejor entre sí, ya que no compiten con las dependencias.
De los proyectos de código abierto de esta manera nivo , aquí está su configuración de lerna .
¿Cómo aparecen las dependencias duplicadas entonces? ¿Y cómo eliminarlos?
Supongamos que tiene un proyecto simple con el siguiente package.json :
{ "name": "demo-project", "version": "1.0.0", "dependencies": { "@nivo/bar": "0.54.0", "@nivo/core": "0.53.0", "@nivo/pie": "0.54.0", "@nivo/stream": "0.54.0" } }
Veamos dónde @nivo/core :
npm list @nivo/core
Vemos 4 copias de @nivo/core (3 copias de 0.54.0 y 1 - 0.53.0 ). Pero si cambiamos la versión menor de @nivo/core a 0.54.0 , se eliminarán los duplicados.
El ejemplo actual es simple, pero en la práctica, por supuesto, cada paquete tiene más dependencias, y aún necesita considerar más las dependencias, lo que aumenta la complejidad de la tarea.
Y una vez más, viendo el gran tamaño del paquete, estaba cansado de eliminar manualmente los paquetes duplicados.
En general, es correcto actualizar inmediatamente los paquetes a la última versión, pero no hay tiempo, como siempre, para cambiar las versiones principales, y es largo y difícil seleccionar el paquete apropiado mediante una búsqueda ciega. Después de todo, debe actualizar la versión de dependencia en package.json , instalar nuevas dependencias y luego verificar si los duplicados han desaparecido en la compilación, si no, repita, durante un tiempo prolongado, en promedio, 3-4 minutos por iteración.
Todo esto es monótono y requiere atención, así que decidí automatizar.
Me gustaría conocer los duplicados sin reinstalar las dependencias y reconstruir el proyecto, idealmente la aplicación cli que muestra las opciones de optimización en 10 segundos y todos los duplicados existentes en el proyecto.
La eliminación de tomas se puede dividir en varias subtareas, las consideraremos en orden.
Primera tarea Debe modelar el árbol de dependencia del paquete futuro solo por package.json, dada la deducción estándar, rápidamente, en no más de 100 ms.
Decidí usar package-json para obtener información sobre paquetes y semver para comparar diferentes versiones.
El resultado fue un paquete npm dependencies-tree-builder , modelando de manera inteligente el árbol de dependencias de paquete solo por package.json.
Asignado a un componente separado, porque tal vez alguien lo reutilizará en tareas combinatorias con package.json.
La segunda tarea. Una tarea combinatoria, una enumeración eficiente de opciones para cambiar dependencias, y una comparación de varias opciones para árboles, y por supuesto, la elección de la óptima.
Era necesario comparar de manera cualitativa los árboles resultantes cualitativamente, y tuvimos que tomar prestada la idea de la entropía, como medida cuantitativa del trastorno, tomó la suma de copias duplicadas (del ejemplo anterior es 3).
Sería genial tener en cuenta los pesos de los paquetes (en KB), pero desafortunadamente no encontré un paquete que funcionara rápidamente con pesos, y los que funcionan funcionan durante aproximadamente medio minuto por paquete, por ejemplo , el tamaño del paquete . Dado que funcionan de acuerdo con el siguiente principio: crear un proyecto con una sola dependencia, establecer dependencias, después de lo cual se mide el peso total de la carpeta. Como resultado, no se me ocurrió otro criterio, como el número de copias duplicadas.
Para comprender qué paquete debe cambiarse, se consideran los motivos de los duplicados, más específicamente la fuente y el efecto. La enumeración elimina los efectos duplicados tanto como sea posible, y dado que los efectos se eliminan, también se duplican más tarde.
Como resultado , obtuvimos una pequeña aplicación cli ostap que recomienda versiones óptimas para reducir la cantidad de instancias duplicadas en el paquete.
Comienza simplemente apuntando a package.json de su proyecto.
ostap ./package.json
También puede usarlo para ver rápidamente todas las tomas futuras sin reconstruir el proyecto cambiando solo las versiones en package.json.
ostap ./package.json -s
Como resultado, en mi proyecto, el peso total de los paquetes disminuyó en un 15%.
El repositorio tiene una sección de inicio rápido.
Si usa la división de rutas, puede parecer que algunos paquetes han aumentado de peso, pero la distribución de componentes puede haber cambiado. Es decir, en lugar de copias de dependencias en cada página, la única versión se convirtió en un paquete común para todas las páginas, por lo que debe evaluar el peso total de los paquetes para todas las páginas.
Espero que el artículo haya sido útil. Y alguien ahorrará información de tiempo. Gracias
Referencias para conveniencia nuevamente:
- Paquete que modela el árbol de dependencia de paquete por package.json
Github - Optimizador de dependencias para eliminar duplicados en un paquete
Github
Si tiene ideas interesantes, escriba para emitir en github, lo discutiremos.