Así que el impacto que tiene es que el rendimiento sufre. Tienes tiempos de instalación más largos, paquetes más grandes, construcciones más lentas, y obviamente también riesgos de seguridad por dependencias obsoletas. Y si alguna vez tuviste que hacer una auditoría de seguridad, sabrás que pasar por miles de módulos de Node no es tan agradable, porque tienes que auditar todos ellos. Así que cuantas menos dependencias tenga un proyecto, mejor. Así que este es exactamente el problema que E18E fue creado para resolver, y lo abordamos en tres categorías. Las llamamos los tres pilares del E18E. El primero es sobre la limpieza. Así que revisamos proyectos de código abierto e intentamos reducir las dependencias que utilizan. Eliminamos polyfills innecesarios, por ejemplo, para versiones antiguas de Node, reemplazamos paquetes con alternativas que son más rápidas o más pequeñas.
También tenemos la aceleración, donde simplemente intentamos hacer que los paquetes sean más rápidos. Así que a menudo intentamos apuntar a paquetes que están en la base del ecosistema, por ejemplo, FDL, que se utiliza en todas partes para el acceso al sistema de archivos y todo eso. Así que acelerar eso también acelera muchos otros paquetes que podrían consumir FDL, por ejemplo, y simplemente hace que todo sea un poco más rápido. Lo siguiente es la mejora, porque a veces simplemente no es suficiente hacer que los paquetes existentes sean mejores porque ya están inflados o los mantenedores simplemente no quieren que intervengamos. Así que intentamos idear mejores versiones que sean más rápidas, más ligeras y más pequeñas, que puedas usar en su lugar. Así que ahora quiero profundizar un poco más en estas categorías.
La primera es la de limpieza. Así que lo que realmente hacemos es, como dije, eliminamos polyfills no relacionados y reemplazamos paquetes no cumplidos, eliminamos paquetes de una sola línea que a menudo son como isNumber o isArray o isOdd, cosas así, que en realidad es un complemento de Dan y Ro que puedes instalar ahora cuando usas Vite que haría eso para tu paquete ya, para que no terminen en tu construcción de producción. Pero si ni siquiera quieres instalar esos, eso es lo que hacemos. Vamos a estos proyectos y eliminamos esos en las dependencias. También actualizamos dependencias tan simple como eso, porque a menudo esto es suficiente para obtener todas las cosas buenas como mejor rendimiento y estabilidad porque ya hicimos el trabajo en otro lugar para mejorar algo. Y ahora solo tenemos que asegurarnos de que la nueva versión esté presente en todos los proyectos. Aquí hay uno de estos problemas de GitHub que creamos en nuestro repositorio para rastrear el progreso que hemos hecho. En este ejemplo, hay un paquete pump que simplemente puede ser reemplazado con una funcionalidad nativa de node stream.pipeline porque desde node 10, puedes usar eso y ya no necesitas el paquete pump. Así que si simplemente haces eso, tienes menos dependencias, menos de qué preocuparte. Como puedes ver, entonces tienes una lista completa de paquetes que usan pump. En este ejemplo, tenemos tarfs y pumpify y el tráfico que generan cuando siempre se descargan cada mes. Y la forma en que creamos estas tablas es con un CLI que creé cuando me uní por primera vez a E18E. Y tuvimos que básicamente copiar todo el registro de NPM para eso para agregar índices para que podamos consultar dependencias. Así que podemos saber qué paquete depende de qué para que básicamente podamos crear esas tablas. Un miembro de la comunidad, Roman, en realidad decidió construir un mejor frontend para eso en lugar de solo el CLI.
Comments