ESLint: el Linter JavaScript de próxima generación

 

 

 

  • Clase magistral de tipografía, con Elliot Jay Stocks
  • ¡Registro!

  • Índice
    1. Problemas heredados
    2. Empezando
    3. Archivos de configuración
    4. Comprender el resultado
    5. Complementos
    6. Analizadores personalizados
    7. Mejoras de pelusa
    8. Conclusión
      1. Otras lecturas

    Nicholas C. Zakas empezó a buscar una forma de detectar automáticamente patrones incorrectos. No podía quitarse de la cabeza la idea de un linter con reglas de tiempo de ejecución conectables. Acababa de pasar mucho tiempo aprendiendo sobre Esprima y los árboles de sintaxis abstracta (AST), y pensó para sí mismo: "No puede ser tan difícil crear un linter de JavaScript conectable usando un AST". Fue a partir de esos pensamientos iniciales que nació ESLint. ESLint es un linter de JavaScript que ha aprendido de nuestro pasado colectivo de desarrollo de JavaScript. Se compromete no solo a ser un excelente linter listo para usar, sino también a ser el centro de un excelente y creciente ecosistema de complementos, configuraciones compartibles y analizadores.

     

    Era el verano de 2013 y estaba trabajando en un proyecto para mi empleador, Box . Acababa de terminar de configurar JSDoc como una compilación nocturna usando un complemento para detectar patrones T3 en nuestro código y documentarlos automáticamente. Se me ocurrió que era fácil equivocarse con estos patrones y comencé a buscar una manera de detectar automáticamente patrones incorrectos . Inmediatamente recurrí a JSHint porque ya lo estábamos usando y pensé que podría admitir complementos . Desafortunadamente, no pudo.

    Aún así, no podía sacarme de la cabeza la idea de un linter con reglas de tiempo de ejecución conectables. Acababa de pasar mucho tiempo aprendiendo sobre Esprima y los árboles de sintaxis abstracta (AST), y pensé: "No puede ser tan difícil crear un linter de JavaScript conectable usando un AST". Fue a partir de esos pensamientos iniciales que nació ESLint .

    Nota: "ES" en "ESLint" significa "ECMAScript", el nombre del núcleo del lenguaje JavaScript. Este término se ha vuelto más popular gracias a ECMAScript 6.

    Problemas heredados

    Hice un par de pequeñas contribuciones a JSHint a lo largo de los años y también cocreé CSS Lint , por lo que tenía bastante experiencia escribiendo y modificando linters. Hubo algunas cosas sobre JSHint que me molestaron e intentamos solucionarlas en CSS Lint. Aun así, sentí que CSS Lint no estaba ni cerca de donde me gustaría que estuviera un linter moderno. En JSHint y CSS Lint, vi algunos problemas y decidí que si creaba un nuevo linter, debía resolver tantos de estos problemas como fuera posible.

    Muchos de los problemas son artefactos del legado: así es simplemente como siempre se han hecho las cosas. JSHint, en particular, sufría parte del legado de JSLint (del cual se bifurcó). Pero como comencé desde cero, tuve la oportunidad de mirar estos problemas con ojos nuevos y sin limitaciones en cuanto a sus soluciones. Los problemas que más me interesaba resolver eran:

    1. Tiempo de ejecución único Tanto JSHint como CSS Lint se ejecutan tanto en Rhino como en Node.js; algo que inicialmente vi como un beneficio en el pasado rápidamente se convirtió en un costo significativo. La cantidad de tiempo dedicado a intentar abstraer el motor JavaScript subyacente, así como a mantener la compatibilidad entre los motores, es una gran fuente de dolor y un agujero en el que desaparecen muchas horas de forma regular. No solo fue difícil lograr que el tiempo de ejecución funcionara correctamente en ambos motores, sino que también fue difícil lograr que las pruebas se ejecutaran en ambos motores.
    2. Deshabilitar reglas Un aspecto de JSHint que siempre me molestó fue cómo había que averiguar qué reglas estaban activadas y desactivadas de forma predeterminada. Si bien puedes desactivarlas, las reglas tienen nombres extraños y algunas de ellas no tienen ningún nombre, solo códigos ( W030, por ejemplo). Este fue un problema que abordamos en CSS Lint al hacer obvio qué reglas estaban habilitadas y al darle nombres legibles para los humanos.
    3. Documentación JSHint siempre ha sido bastante escasa en lo que respecta a documentación. JSLint casi no tenía documentación, por lo que la documentación de JSHint fue una mejora. Aún así, descubrir lo que W030significaba fue realmente difícil. Fuimos más allá con la documentación de reglas de CSS Lint y la gente pareció apreciar los ejemplos adicionales. Sentí firmemente que esta era la dirección que tendría que tomar cualquier nuevo linter.
    4. Configurar reglas Otro problema que tuve con JSHint fue cómo algunas reglas debían configurarse truepara habilitarse, mientras que otras debían configurarse falsepara habilitarse. En realidad, esto no fue culpa de JSHint, ya que ese extraño comportamiento fue heredado de su predecesor, JSLint. Aún así, incluso después de años de usar JSHint, siempre tenía que buscar qué reglas debían configurarse y de qué manera.
    5. Niveles de error de reglas JSHint, como JSLint antes, obliga a que todas las reglas tengan la misma gravedad: error. En mi experiencia, a menudo es conveniente introducir gradualmente el uso de ciertas reglas, permitiendo que se establezcan como advertencias que no interrumpan la construcción y luego hacerlas cumplir estrictamente. CSS Lint te permitía configurar advertencias y errores por separado, y eso terminó funcionando muy bien, así que quería que ESLint tuviera la misma capacidad.
    6. Escriba sus propias reglas Vi que tanto JSHint como CSS Lint luchaban con el problema de no poder satisfacer la demanda de reglas. Hubo interminables debates sobre si una regla era lo suficientemente general como para ser incluida, y si no lo era, entonces el usuario estaba estancado. No quería que ESLint fuera la única fuente de reglas. No quería tener esos mismos debates, y la única manera de que eso sucediera era si cada uno pudiera escribir sus propias reglas. Así que resolví que ESLint no debería ser sólo una herramienta, sino que debería ser el centro de un ecosistema que permitiera a otros desarrolladores ampliarlo fácilmente.

    Con todo esto en mente, y con la ayuda de más de 200 contribuyentes en los últimos dos años, ESLint se ha convertido en el linter JavaScript sólido y flexible que siempre esperé que fuera.

     

    Empezando

    La parte más difícil de incorporar un nuevo linter en su proyecto es configurarlo por primera vez. Desde la instalación hasta la configuración inicial, puede llevar una cantidad significativa de tiempo lograr que esos primeros resultados de linting aparezcan y sean útiles. Con ESLint, el equipo ha trabajado duro para comenzar lo más rápido posible.

    Puede instalar ESLint desde npm escribiendo:

    $ npm install -g eslint

    Esto instala ESLint globalmente, lo cual es útil con fines de demostración. Muchos proyectos instalan ESLint localmente (simplemente elimine el archivo -g) para que pueda interactuar con su proceso de compilación.

    La mayoría de los linters requieren que usted revise y configure manualmente las opciones de configuración antes de usar linters por primera vez. Esto puede implicar buscar en la documentación para intentar descubrir qué reglas desea aplicar. Si bien es posible que quieras hacerlo eventualmente, ESLint puede guiarte a través de los conceptos básicos para configurar tu configuración inicial. Cambie a un directorio con los archivos que desee eliminar y escriba:

    $ eslint --init

    Se le pedirá que responda algunas preguntas sobre el estilo de JavaScript que escribe y que le permite a ESLint configurar un archivo de configuración adecuado para comenzar.

    $ eslint --init? What style of indentation do you use? Tabs? What quotes do you use for strings? Double? What line endings do you use? Unix? Do you require semicolons? Yes? Are you using ECMAScript 6 features? No? Where will your code run? Browser? Do you use JSX? No? What format do you want your config file to be in? cssSuccessfully created .eslintrc file in c:UsersNicholasprojectspersonaltmp

    Observe que se le pregunta si está utilizando ECMAScript 6 y JSX; Fuera de la caja, ESLint admite ambos a través de opciones de idioma . De hecho, ESLint fue el primer linter que es totalmente compatible con ECMAScript 6 y JSX, lo que lo ha hecho bastante popular entre quienes usan React y webpack .

     

    El eslint –initproceso configura un archivo de configuración de ESLint, .eslintrc , en el directorio actual. ESLint usa este archivo para determinar qué reglas aplicar al evaluar su código. Los archivos de configuración pueden estar en formato JSON o CSS, y encontramos que la mayoría de los usuarios prefieren CSS.

    Después de eso, puede comenzar a linting archivos pasando uno o más nombres de archivos o directorios:

    $ eslint test.js src/

    Archivos de configuración

    Los archivos de configuración son los que hacen que ESLint sea tan flexible. Dentro de su archivo .eslintrc , puede especificar múltiples configuraciones, que incluyen:

    • Reglas que desea ejecutar en archivos
    • Variables globales que deberían estar presentes en los archivos.
    • Entornos en los que se ejecutan archivos
    • Una configuración base para heredar
    • Complementos para cargar
    • Analizadores alternativos para usar

    Para comprender mejor los archivos de configuración, resulta útil ver un ejemplo. Aquí hay un archivo de ejemplo generado a partir de eslint –init:

    rules: indent: - 2 - tab quotes: - 1 - double linebreak-style: - 2 - unix semi: - 2 - alwaysenv: browser: trueextends: 'eslint:recommended'

    La primera sección de este archivo es rulesla que especifica la configuración de las reglas . Los nombres indent, quotesy linebreak-styletodos semicorresponden a las reglas de ESLint. Cada regla se configura con una matriz, cuyo primer elemento es la gravedad de la regla. La gravedad de la regla es uno de tres valores:

    • 0: deshabilita la regla por completo
    • 1: habilita la regla como advertencia
    • 2: habilita la regla como error

    La diferencia entre advertencias y errores es que las advertencias no afectarán el código de salida de ESLint. Por ejemplo, si tiene diez advertencias y ningún error, el código de salida sigue siendo 0. Las reglas configuradas como errores harán que el código de salida sea 1 si ese error está presente. De esta manera, puede habilitar nuevas reglas sin bloquear un proceso de compilación configurándolas como advertencias. Puedes cambiar las reglas para que sean errores más adelante cuando estés listo.

    Cada regla también puede tener varias opciones asociadas. En el ejemplo anterior, la indentregla se ha tabespecificado como una opción. Eso indica la regla de que estos archivos deben usar tabulaciones para sangría en lugar de espacios. Otras reglas tienen sus propias opciones y las opciones de cada regla se detallan en su propia página de documentación .

    Puede especificar entornos utilizando la envclave. Los entornos proporcionan variables globales predefinidas y, en algunos casos, alteran ligeramente el funcionamiento del analizador. Los dos entornos más populares son browsery node.

    Quizás el aspecto más poderoso de los archivos de configuración es la extendsclave, que le permite heredar la configuración de uno o más archivos de configuración. La eslint:recommendedconfiguración está integrada en ESLint y contiene las reglas que el equipo recomienda para evitar errores comunes (puede ver qué reglas se recomiendan en la página de documentación ). También puede heredar de una configuración compartible , que es un archivo de configuración definido como un paquete npm para que pueda compartirse fácilmente entre proyectos.

     

    Comprender el resultado

    El formateador predeterminado para la salida de ESLint, diseñado por Sindre Sorhus , es otro gran ejemplo de cómo ESLint trabaja duro para ser útil a los usuarios. A continuación se muestra un resultado de ejemplo:

    $ eslint test.jstest.js 1:11 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style 2:1 error Unexpected console statement no-console 3:9 warning Strings must use doublequote quotes✖ 3 problems (2 errors, 1 warning)

    Los resultados de cada archivo se separan con un encabezado (en este caso, test.js) y luego cada error y advertencia se enumera debajo con cuatro datos:

    1. El número de línea y el número de columna que activaron la regla.
    2. La gravedad de la regla (error o advertencia)
    3. El mensaje
    4. La regla que generó el mensaje.

    Descubrimos que toda esta información es clave para ayudar a los desarrolladores a comprender qué solucionar. En JSLint y JSHint, es difícil saber cómo eliminar un mensaje (lo que dio lugar al sitio de errores de JSLint). Con ESLint, la regla a configurar está ahí en la salida.

    ESLint también incluye otros formateadores diseñados para facilitar la integración con otras herramientas. Y como ESLint tiene que ver con la extensibilidad, también puedes crear y distribuir tus propios formateadores .

    Complementos

    Como se mencionó anteriormente, uno de los objetivos originales de ESLint era permitir a los desarrolladores escribir sus propias reglas personalizadas y conectarlas en tiempo de ejecución. ESLint logra esto a través de complementos . Un complemento de ESLint puede contener cualquier cantidad de reglas personalizadas que luego se pueden distribuir y utilizar.

    Por ejemplo, eslint-plugin-react es un complemento ESLint popular que tiene reglas adicionales dirigidas específicamente a la biblioteca React. Para usar eslint-plugin-react, primero debes instalarlo a través de npm:

    $ npm install eslint-plugin-react --save-dev

    Luego, en su archivo de configuración, indica que eslint-plugin-react debe cargarse usando la pluginsmatriz. Después de eso, puedes configurar reglas individuales dentro del complemento tal como lo harías con cualquier otra regla de ESLint:

    plugins: - reactrules: react/display-name: 2 indent: - 2 - tab quotes: - 1 - double linebreak-style: - 2 - unix semi: - 2 - alwaysenv: browser: trueecmaFeatures: jsx: trueextends: 'eslint:recommended'

    Puede omitir el eslint-plugin-prefijo de forma segura cuando utilice el nombre de un complemento en el archivo de configuración, por lo que reactes suficiente para identificar el complemento. La regla react/display-nameestá destinada a ser un error. El react/prefijo le permite a ESLint saber que esta regla proviene de un complemento y no del núcleo.

     

    Hay más de 80 complementos de ESLint publicados en npm y muchos de ellos los utilizan los equipos internamente en sus propias empresas. Cualquiera puede crear sus propias reglas personalizadas y ESLint Yeoman Generator para guiarlo a través del proceso.

    Analizadores personalizados

    Otra forma de personalizar ESLint es especificando analizadores personalizados . De forma predeterminada, ESLint utiliza el analizador Espree (una bifurcación de Esprima) que proporciona compatibilidad nativa con ECMAScript 6 y JSX. Sin embargo, ESLint puede utilizar cualquier analizador que genere un AST compatible con ESTree. Es esta capacidad la que llevó a ESLint a ser el primer linter que admite Babel mediante el uso de babel-eslint .

    El analizador babel-eslint es un adaptador que hace que Babel genere un formato AST que ESLint pueda entender. Como resultado, usar babel-eslint significa que ESLint puede comprender y trabajar con casi todas las sintaxis experimentales que admite Babel (por supuesto, existen algunos problemas de compatibilidad cuando se trata de funciones experimentales). Para usar babel-eslint, primero instálelo:

    $ npm install babel-eslint --save-dev

    Luego especifique la parserclave en su archivo de configuración:

    parser: babel-eslintrules: react/display-name: 2 indent: - 2 - tab quotes: - 1 - double linebreak-style: - 2 - unix semi: - 2 - alwaysenv: browser: trueecmaFeatures: jsx: trueextends: 'eslint:recommended'

    Cuando ESLint se ejecuta usando este archivo de configuración, intercambiará babel-eslint por Espree cuando analice su código.

    Desacoplar el linter del analizador es una de las innovaciones importantes en ESLint que nos ha permitido avanzar rápidamente para admitir una amplia variedad de casos de uso.

    Mejoras de pelusa

    Los Linters han funcionado tradicionalmente de la misma manera: elabora una lista de archivos para eliminar, elimina cada archivo y luego informa los resultados. Sin embargo, el equipo de ESLint siempre está buscando formas de hacer que la experiencia de linting sea más efectiva y eficiente. Recientemente, el equipo agregó un par de características nuevas que realmente enfatizan cuán poderoso es ESLint:

    • La --fixopción de línea de comando le dice a ESLint que intente solucionar automáticamente tantos problemas como sea posible. Las correcciones solo se aplican cuando es seguro hacerlo y verá los problemas que quedaron sin solucionar. Entonces, ahora, en lugar de volver a sus archivos para insertar un punto y coma faltante o sangrar correctamente algún código, ESLint puede hacerlo por usted. Esto es especialmente útil cuando introduces ESLint en un proyecto por primera vez, ya que significa que no tienes que arreglar manualmente cada archivo.
    • Las --cacheopciones de la línea de comando le dicen a ESLint que realice un seguimiento de los archivos que no tuvieron problemas para que las ejecuciones futuras solo eliminen los archivos que hayan cambiado. Si ejecuta ESLint repetidamente sobre una base de código grande, esto puede ahorrarle mucho tiempo.

    Conclusión

    ESLint es un linter de JavaScript que ha aprendido de nuestro pasado colectivo de desarrollo de JavaScript. Nuestros paradigmas de desarrollo se han alejado de enfoques de jardín amurallado y de talla única hacia una era de componentes pequeños y componibilidad. El equipo de ESLint sabe que el desarrollo de JavaScript en 2015 es muy diferente de cuando se lanzó JSLint por primera vez, y que ningún equipo por sí solo puede dar cuenta adecuadamente de todas las diferentes variaciones y deseos de los desarrolladores de todo el mundo.

    Es por eso que ESLint se compromete no solo a ser un excelente linter listo para usar, sino también a ser el centro de un excelente y creciente ecosistema de complementos, configuraciones compartibles y analizadores.

    Otras lecturas

    • Terribles errores de JavaScript que se deben evitar con un analizador de código estático
    • Stylelint: la hoja de estilo Linter que siempre quisimos
    • Por qué es importante el estilo de codificación
    • El camino hacia una increíble facilidad de CSS con la función lineal()

    (ml, og, mrn)Explora más en

    • Codificación
    • Flujo de trabajo
    • javascript
    • Pruebas





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    ESLint: el Linter JavaScript de próxima generación

    ESLint: el Linter JavaScript de próxima generación

    Clase magistral de tipografía, con Elliot Jay Stocks ¡Registro! Índice Problemas heredados

    programar

    es

    https://aprendeprogramando.es/static/images/programar-eslint-el-linter-javascript-de-proxima-generacion-860-0.jpg

    2024-05-20

     

    ESLint: el Linter JavaScript de próxima generación
    ESLint: el Linter JavaScript de próxima generación

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20