ESLint Uno para Todos Hecho Fácil

Hola a todos, muchas gracias por invitarme y espero que estén disfrutando de la conferencia hasta ahora. Es una pena que no haya podido ir a Berlín en persona esta vez, pero espero que encuentren interesante mi tema de hoy.

Así que primero, permítanme presentarme un poco. Mi nombre es Anthony Fu y soy el miembro de coaching de Vit, Vue y Nuxt. También creo algunos proyectos de código abierto como Vitest, Lightdiv, Unocetus, etcétera. También mantengo algunos proyectos como ESLink, StyleAsync, Shiki, 2slash, y así sucesivamente. Actualmente estoy trabajando en Nuxt Lab en el equipo de framework.

Así que, como pueden ver, estoy bastante entusiasmado con el código abierto, lo que me ha llevado a trabajar en muchos proyectos. Me encanta construir herramientas y encontrar soluciones a los problemas que encuentro. Por ejemplo, la diapositiva que están viendo está impulsada por Slidev, una herramienta de presentación basada en markdown que está construida sobre tecnologías web. Nació cuando encontré que las herramientas existentes no eran lo suficientemente flexibles para presentar mi código. De manera similar, cuando miré ESLink y su ecosistema hace unos meses, encontré muchas cosas bastante interesantes con mucho potencial, pero que aún no se habían explorado completamente. Así que hoy me gustaría compartir con ustedes algunos de mis hallazgos y prácticas durante mis recientes exploraciones al respecto.

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.

Antes de hablar sobre las nuevas cosas emocionantes, permítanme repasar rápidamente las herramientas para migrar su configuración heredada al nuevo FlatConfig en caso de que las necesiten. Tienen un CLI como eslink-migrate-config que convierte automáticamente su archivo de configuración heredada al FlatConfig. Algunas utilidades de tiempo de ejecución para las compatibilidades también se introducirán automáticamente a lo largo del camino. Les recomendaría que revisen la documentación de ESLink y la guía de migración para obtener instrucciones más detalladas.

Y ahora, hablemos de las nuevas cosas geniales y posibilidades que habilita este nuevo formato FlatConfig. La primera es el eslink-config-inspector, una herramienta de pasos visualizada que les permite inspeccionar y jugar con su configuración final resuelta. Pueden probarlo ejecutando eslink-inspect-config en su CLI bajo la raíz del proyecto. Se abrirá una página del navegador con una interfaz como la que ven a la derecha.

Así que lo primero que hace es renderizar cada elemento de configuración que tienen. Pueden ver que todas las listas de configuración están aquí, y porque es plana. Aquí tengo una configuración bastante compleja con muchos elementos de configuración, pero con el nombre proporcionado por cada configuración, pueden ver y entender fácilmente el propósito de cada uno de ellos. También pueden expandir cada elemento para ver cómo contribuye a la configuración final, como cuántas reglas habilita y cuál es el archivo objetivo, etc. Y en cada regla, también pueden ver sus opciones, una breve descripción, y también un enlace a su página de documentación.

Gracias a ESlinks, pueden tener diferentes conjuntos de reglas aplicadas a diferentes tipos de archivos y tener más granularidad en sus rutas de archivo exactas. En el inspector de configuración, también pueden ingresar las rutas de archivo para probar cómo se habilitan las reglas para ese archivo. Por ejemplo, aquí puedo escribir folo.json para ver estas reglas aplicadas a este archivo, y puedo también cambiar a pack.json, y puedo ver que también hay una regla específica que solo se aplica a pack.json, y aquí están todas las reglas fusionadas para esta ruta de archivo.

Y en la otra pestaña, también pueden navegar por cada regla que está disponible en su proyecto, dado el proyecto que han instalado, y pueden filtrarlas y ver qué reglas están usando y cuáles no, y cuáles son las recomendadas, y cuáles están obsoletas. Aquí tengo mi preset de configuración como ejemplo. El marco de código aquí refleja mi configuración de ESlinks en mi disco. La configuración es una función de fábrica que toma algunas opciones bastante de alto nivel. Con el inspector de configuración, podemos ver cómo se resuelve en función de las opciones que proporcionamos. También podemos intentar cambiar algunas opciones para ver cómo afecta el resultado. Por ejemplo, si quiero tener TypeScript habilitado para este proyecto, puedo simplemente cambiar el TypeScript de false a true. Cuando lo guardo, pueden ver que aparecen tres nuevos elementos relacionados con TypeScript en esta configuración. Opcionalmente puedo cambiar esto a una opción y proporcionar la ruta a mi tsconfig.json, Cuando lo guardo, habilitará las reglas conscientes de TypeScript para ciertos tipos. Pueden ver que esto tiene mucho potencial. Pueden cambiar muchas cosas. Por un ejemplo más, pueden deshabilitar view, pueden habilitar react.true. Cuando lo guardan, pueden ver las cosas conscientes de React y react-typeScript.

Esos son automáticos sin que te preocupes por los detalles. Para facilitar la personalización de la configuración, también hice una pequeña biblioteca llamada eslink-flag-config-utilities. Por ejemplo, aquí está la configuración de banderas que podrías tener. Depende de cómo se construya cada configuración compartida, algunas podrían ser un objeto planificado, algunas podrían ser un array, y algunas podrían ser un constructor que devuelve un objeto, array, o incluso una promesa. Cuando los usas juntos, generalmente es tu responsabilidad unirlos con su manejo adecuado en un solo array.

Con las utilidades de configuración, hice las utilidades llamadas Compose, que resolverán automáticamente diferentes tipos de configuración y resolverán la promesa y las fusionarán. También proporciona algunas acciones de recorte donde puedes insertar configuraciones adicionales donde quieras o anular alguna configuración sin la necesidad de manejar la fusión manualmente. Y luego, gracias a la flexibilidad y también al contexto completo disponible en la configuración de banderas, también hace posible la generación de tipos. Simplemente envuelve todo el array de configuración que esperas con la función de generación de tipos, puede generar un archivo de declaración local de TypeScript basado en los plugins que has instalado. Esto te proporciona el autocompletado y la verificación de tipos para todas las reglas que estás usando. Y así, aquí, me gustaría retomar el título, Uno para Todos. Con la máxima flexibilidad y personalización que tenemos, no es posible tener una sola configuración compartida que cubra todos los diferentes tipos de proyecto.

Así que aquí, puedo hacer una comparación rápida para mostrar lo que quiero decir. En la configuración de banderas, una configuración compartida puede ser una función de fábrica que toma opciones del usuario, lo cual no podíamos hacer en la configuración Lexi. Imagina si quiero que mi configuración funcione tanto en proyectos TypeScript como no TypeScript, Vue y proyectos no Vue. Usualmente necesitaría configurar un monorepo y publicar múltiples configuraciones para diferentes combinaciones. Como puedes ver, no escala bien, y estamos duplicando la cantidad de combinaciones para cada opción. La configuración de banderas te permite proporcionar más opciones semánticas y activar cada característica dinámicamente, haciendo que una sola configuración pueda adaptarse a diferentes proyectos. Y debido a eso, podríamos tener una abstracción de alto nivel para absorber la complejidad subyacente y proporcionar una interfaz de configuración mínima como Prettier, donde los usuarios finales no necesitan preocuparse por los detalles subyacentes pero aún tienen todos los controles para hacerlo cuando quieran hacerlo.

La configuración de banderas también hizo posible que MetaFramework proporcione configuraciones conscientes del proyecto. Por ejemplo, en Nuxt, tenemos un enrutamiento basado en archivos, componentes de auto-importación, directorios de API del servidor, etc. Los archivos bajo diferentes carpetas o diferentes nombres pueden tener diferentes propósitos con diferentes restricciones. En Nuxt, teníamos un módulo Nuxt ESLink que genera una subconfiguración de ESLink basada en la configuración del proyecto del usuario, donde los usuarios pueden extender y seguir agregando sus propias reglas personalizadas. Esta es una dirección de posibilidad con la configuración de banderas que estamos explorando actualmente, pero creemos que habrá muchos más enfoques interesantes que llegarán a la comunidad para diferentes MetaFramework o cosas de propósito general.

Otro tema que me gustaría mencionar hoy es el hecho de que ESLink es mucho más que un enlazador. Para mí, veo ESLink como una poderosa herramienta AST mutua que tiene un gran ecosistema a sus espaldas. Por ejemplo, quiero decir que ESLink también puede ser un formateador. Ciertamente no es nuevo, ya que muchos proyectos han estado usando ESLink de esa manera desde el principio. Pero este tema es en realidad un poco controvertido, lo que podrías escuchar a la gente decir que deberías usar un formateador dedicado como Pretier o Dprint en su lugar.

Pero para mí, veo que todas estas reglas estilísticas requieren mucho mantenimiento del equipo de ESLink. El año pasado, los equipos de ESLink y Tysquare ESLink decidieron deprecar esas reglas estilísticas del núcleo. Y luego inicié el proyecto estilístico de ESLink, reuniendo todas estas reglas estilísticas para JavaScript, Tysquare y JSX en estas organizaciones y crear una comunidad para mantener ellas. Sigo usando ESLink como formateador ya que veo que tiene mucha más flexibilidad y personalización que Pretier debido a la naturaleza enchufable de ESLink. Si estás usando VS Code, puedes configurar editor.codeaction on save para corregir automáticamente los errores de ESLink al guardar. Y también puedes usar eslink.rules.customization para silenciar esas reglas estilísticas en tu IDE. Así funcionan más como un formateador. Para los otros editores de código, creo que hay opciones similares para hacer lo mismo.