Así que, 11 años desde que ESLink salió, en este momento, es fácilmente una de las herramientas más populares en el ecosistema de JavaScript que casi todos los proyectos utilizan. A pesar de que ha estado presente durante tanto tiempo, es una herramienta que sigue mejorando y evolucionando constantemente.
Hoy, me gustaría darles un tema aburrido y ambicioso, ESLinked, uno para todos, hecho fácil. Para compartir con ustedes algunas de las nuevas perspectivas y patrones de uso de ESLinked con las últimas características que acaban de lanzar.
Así que probablemente ya saben que ESLinked v9.0 fue lanzado hace unos 7 meses. El principal destaque de esta versión importante es el lanzamiento del nuevo sistema de configuración para ESLinked, llamado FlatConfig. En caso de que nunca hayan oído hablar de él o no hayan profundizado en la documentación aún, aquí les hago una rápida comparación entre la configuración heredada ESLinked-RC y el nuevo FlatConfig para ustedes.
Diferenciar entre esos dos formatos de configuración es bastante sencillo. La configuración heredada se llama .eslinked-rc, que soporta varias extensiones, que también podría leerlo desde su package.json. El FlatConfig, por otro lado, solo se cargaría desde eslinked.config.js, un archivo de configuración de JavaScript como una única fuente de verdad.
Y cuando se trata de reutilizar la configuración compartida, los formatos de configuración heredados utilizan implícitamente propiedades de extensión basadas en convenciones para cargar la configuración desde sus módulos locales de node. Necesitarían aprender un poco la convención para saber cómo se resuelve. Mientras que el FlatConfig usará importaciones nativas, donde es más explícito y les da mucho más control.
Y para los plugins, en la configuración heredada, toma un array de cadenas, que nuevamente es basado en convenciones y acoplado con el nombre del paquete del plugin. Ahora en el FlatConfig, toma un objeto nombrado para los plugins. Esto significa que ahora pueden renombrar plugins fácilmente o cambiar a un fork sin verse obligados a cambiar cada regla en su configuración.
Además, debido a la naturaleza inherente de las extensiones, podría resultar en una estructura de árbol muy compleja en la configuración compartida, porque la configuración compartida también puede tener extensiones anidadas dentro. En el FlatConfig, se vuelve mucho más simple. Cuando importan explícitamente la configuración compartida como múltiples objetos o arrays, y pueden componerlos en uno solo plano, y por eso también se llama FlatConfig.
Y para un poco más de contexto, aquí hay un gráfico que dibujé para demostrar la línea de tiempo. Aunque el FlatConfig podría sonar nuevo para algunos de ustedes, en realidad ha sido planeado durante 5 años ya. El RFC fue creado en enero de 2019. La primera imputación está disponible en la versión 8.21, como experimental, que fue hace dos años. Se vuelve estable en la versión 8.45, y luego se convierte en el predeterminado en la versión reciente 9. Entre tanto, el equipo de ESLink ha publicado múltiples publicaciones en el blog para explicar la razón por la que quieren introducir un nuevo formato, y compartir la hoja de ruta del lanzamiento. Es mucho esfuerzo invertido en este plan de cinco años. Así que un gran respeto al equipo de ESLink.
Como mencionamos en las diapositivas anteriores, el mayor beneficio de FlatConfig es que ahora está en JavaScript, donde tienen el control total. Utiliza importación nativa para resolver los plugins y las configuraciones, haciendo la herencia y la sobrescritura mucho más simples. Porque está completamente en JavaScript, la configuración compartida puede ser una función de fábrica que toma las opciones del usuario, y el usuario puede tener mucha más capacidad para hacer personalizaciones a sus necesidades específicas.
Comments