Hasta hace poco, en todos los proyectos del frente, los desarrolladores de Dodo Pizza Engineering usaban tslint, una herramienta útil que le indica cuándo
desordenó el código, hizo imprecisiones, ayuda a mantener el código en el mismo estilo y corrige muchos comentarios. Pero entonces tslint tomó y murió. Debajo del corte, te diré por qué sucedió, cómo dejar de derramar lágrimas sobre el difunto y cambiar a la herramienta de eslint, y también mostrar algo muy íntimo.
De hecho, todo comenzó hace mucho tiempo: la última versión del núcleo tslint ya fue en 2016. Y este es el momento en que es hora de comenzar a decir "último", si alguien todavía dice "último", porque ese lanzamiento fue realmente el último. El 19 de febrero de 2019, se publicó una
publicación oficial para detener el desarrollo de tslint. En él, la compañía de desarrollo (por cierto, ni siquiera es Microsoft) recomienda encarecidamente a todos que cambien a Eslint, ya que sus esfuerzos ahora estarán destinados a mejorar el soporte de TypeScript en esta interfaz.
Un idioma, una pila, una comunidad
Microsoft ve TypeScript como el lenguaje principal de desarrollo web, que debería suplantar Java / ECMA Script. Obviamente, un objetivo tan ambicioso implica una sola pila de herramientas para todo el desarrollo front-end. Esto debería simplificar enormemente la migración de la gran comunidad JS a TypeScript. Además de la garantía de confianza de Microsoft, eslint tiene una mejor arquitectura que tslint. Por ejemplo, puede conectar analizadores, y hay más opciones de reglas conectadas.
Microsoft no sería él mismo si solo se quisiera. Digamos lo que digamos sobre la calidad de su software, hacen excelentes herramientas de desarrollo (y, por cierto, dispositivos de entrada). Así que esta vez no vinieron con las manos vacías, sino que escribieron
un plan de migración . De acuerdo con este plan, el desarrollo de las reglas de tslint ya se suspendió el 1 de agosto de 2019, y el desarrollo de tslint cesará el 1 de noviembre de 2019. Aunque, para ser honesto, el desarrollo se suspendió hace mucho tiempo (ver arriba para la última versión).
Aquí debería resultar obvio para el lector que es hora de cambiar a eslint, no hay otra opción. Para endulzar la píldora, vale la pena decir que:
- Si bien tslint se centra en TypeScript con un mayor énfasis en el uso correcto de los tipos y la verificación de sintaxis, eslint cubre todo lo que puede estar en el frente, incluida la sintaxis de los componentes React;
- eslint tiene muchas más reglas predefinidas;
- existen reglas (y complementos) que verifican el código a nivel de bloque (duplicación de código, complejidad percibida, etc.);
- hay complementos que no comprueban el código en absoluto, sino, por ejemplo, expresiones regulares.
En general, parece que la transición a un nuevo linter, que es un producto convencional, nos abrirá todo un mundo de oportunidades nunca antes vistas. Bueno, vamos a intentarlo!
Agregar eslint al proyecto
Hablaré sobre la migración de las reglas a continuación. Mientras tanto, configure un proyecto para trabajar con eslint.
Si ya tiene un proyecto con tslint, primero elimine todos los paquetes relacionados con tslint: tslint, tslint-react, tslint-config-prettier, etc.
Ahora agregue paquetes eslint al proyecto (configure todo como devDependencies):
- eslint mismo;
- @ typescript-eslint / parser: motor para analizar TypeScript;
- @ typescript-eslint / eslint-plugin - conjuntos de reglas para TypeScript
Configuración mínima de Eslint
Cree el archivo de configuración .eslintrc.json. Eslint admite muchos formatos de archivo para su configuración, pero JSON parece el más conveniente. Así es como se ve la opción de trabajo mínima:
{ // "env": { // "browser": true, // ES6 "es6": true, // ES2017 "es2017": true }, // "extends": [ // eslint "eslint:recommended", // "plugin:@typescript-eslint/eslint-recommended", // TypeScript "plugin:@typescript-eslint/recommended", // TS, "plugin:@typescript-eslint/recommended-requiring-type-checking" ], // "parser": "@typescript-eslint/parser", "parserOptions": { // TS "project": "tsconfig.json", "tsconfigRootDir": ".", }, // TypeScript "plugins": ["@typescript-eslint"], "rules": {} }
La sección
env le dice a eslint sobre las opciones de su proyecto. En mi ejemplo, este es un proyecto para el navegador (es decir, el código funcionará en el navegador). Escribir para Node.JS - set node: true. Las dos opciones siguientes indican el dialecto del JS que se está probando. En general, revisaremos el código para TypeScript, pero si su proyecto también tiene código para JS, no olvide ajustarlos. Por nosotros mismos, decidimos establecer estos parámetros en el mismo valor que target en tsconfig.json.
No hay nada controvertido sobre los conjuntos de reglas estándar de eslint, como el punto y coma requerido al final de las expresiones o espacios / pestañas. Todas las reglas son excepcionalmente útiles. Puede ver qué reglas y con qué nivel se incluyen
aquí .
La siguiente línea necesita
deshabilitar la mitad de las reglas. Esto es necesario porque no funcionan con TypeScript y, en lugar de funcionar normalmente, arrojarán muchos errores.
Luego, debe conectar las reglas recomendadas de TypeScript en una bolsa separada. Aquí debe tener en cuenta que
las reglas generales de sintaxis (como la prohibición de var) funcionarán así.
Pero para las reglas que
usan tipos TS (por ejemplo, @ typescript-eslint / no-innecesaria-tipo-aserción), se necesita el motor TypeScript. Y el motor necesitará el archivo tsconfig.json, cuya ruta debe especificarse.
En tsconfig.json, en Dodo Pizza Engineering generalmente especificamos pruebas de exclusión y descarte para que no se generen con el proyecto. Pero para que eslint funcione, debe especificar e incluir. Es decir, todos los archivos que deben estar incluidos deben incluirse explícitamente en el proyecto. Sin esto, eslint maldecirá en cada archivo que encuentre: "El archivo no está en el proyecto, no haré nada, arrojaré un montón de errores". Hay una opción sin especificar explícitamente los archivos de proyecto: establezca
createDefaultProgram: true parámetro
createDefaultProgram: true . Esto, en esencia, significa: "Todo lo que encuentras es Parsi". Pero los desarrolladores desaconsejan hacerlo debido a una caída significativa en el rendimiento.
Si usa ForkTsCheckerWebpackPlugin para procesar archivos TypeScript, reemplace
tslint: true con
eslint: true en sus parámetros (en webpack.config.ts).
También vale la pena configurar el lanzamiento del linter desde la línea de comandos. Antes de eso, agregue este valor a la sección de scripts en
package.json :
"eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json",
La primera línea simplemente inicia la comprobación de eslint sin construir el proyecto. El segundo muestra la configuración actual de eslint, que le permite ver la configuración de los parámetros de la regla.
En esta versión, eslint ya funcionará en el proyecto e incluso capturará algunos bancos de arena: redefinir los globales, las variables no utilizadas, etc.
Configurar el código de Visual Studio
Después de haber recorrido todo este camino, ya puede iniciar el linter desde la línea de comandos. También se lanzará implícitamente al construir el proyecto. Pero en Visual Studio Code no veremos comentarios de la interfaz. ¿Cómo es eso?
Hay un complemento de eslint para el estudio (dbaeumer.vscode-eslint), necesita ser instalado. Después de eso, nada funcionará de todos modos, nada será enfatizado y corregido. Por qué Debido a que el complemento tiene una configuración, que dice que necesita trabajar solo en archivos JavaScript.
Esta configuración engañosa no se realiza en la interfaz de usuario, por lo que debe ir al archivo de configuración del estudio y agregar manualmente los idiomas que necesita al parámetro eslint.validate. Se puede encontrar una lista completa de idiomas en las entrañas de la documentación del estudio. Así es como se ve esta configuración con nosotros:
"eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ],
Después de eso, reinicie el estudio y todo finalmente comenzará a funcionar.
Ahora queda por configurar las reglas
El proyecto está configurado. Ahora sobre las reglas, porque en el ejemplo anterior la lista de reglas estaba vacía.
Debo decir que tslint no nos impidió equivocarnos en el código formalmente correcto. Por ejemplo, olvida esperar. Eslint puede encontrar tales errores semánticos y maldecirlos: informar que el valor de retorno es Promesa, pero por eso, por alguna razón, esperar no está escrito. Esto también incluye problemas estilísticos de complejidad media: el uso de una función o lambda, etc., que Prettier ya no puede hacer.
En cuanto a reglas simples: posición de corchetes, pestañas vs. espacios, etc., se cree que deberían ser entregados a Prettier o un paquete similar. Pero de todos modos, deberían dejarse: esta es la última frontera, que aún puede detener al desarrollador negligente del ensamblaje del proyecto caído. Además, esta línea se puede automatizar: por ejemplo,
husky , le permite iniciar la interfaz automáticamente para cada confirmación.
Decidimos
no migrar ninguno de los conjuntos de reglas tslint que tenemos. Y crea tu propio conjunto desde cero.
Hay conjuntos de reglas predefinidas para eslint:
- ESLint Recommended es un conjunto neutral de reglas que se hace con la idea de no generar holivars. Solo se incluyen las comprobaciones obviamente necesarias: variables no utilizadas, etc. Todos los conjuntos posteriores extienden este.
- Google: ya hay una razón para holivar: para la sangría hay estrictamente espacios, se requiere un punto y coma.
- AirBnB: también hay reglas de estilo estrictas, incluido un punto y coma obligatorio.
- Standart: aquí se prohíben los punto y coma, pero también se prohíben las comas finales.
No nos gustó ninguno de los paquetes confeccionados. Esto puede sonar extraño, pero es importante para nosotros cambiarnos a un nuevo linter, evitando guerras estilísticas. Si escribimos así en todas partes (las pestañas, sin punto y coma, las comas finales son obligatorias), entonces déjelo así: lo principal es que es lo mismo en todos los proyectos.
Sexo prometido: su propio conjunto de reglas
Honestamente, mostrar tu conjunto de reglas de Eslint es como una chica mostrando pechos: no hay más secretos. Pensé durante mucho tiempo si valía la pena hacer esto. Pero, después de consultar con otras chicas, decidí que valía la pena.
Comenzaré con los complementos que usamos:
- reaccionar: comprueba el código del componente de reacción. Conjunto básico de reglas más las nuestras. De lo importante: nos ahogamos por componentes funcionales puros;
- react-hooks: reglas de los desarrolladores de react sobre el uso de ganchos;
- promesa: comprueba si hay errores comunes al usar Promise. Funciona un poco extraño con el código TypeScript. De lo importante: tratamos de usar Promise en todas partes y no usar callbacks y luego / catch debido a una mejor legibilidad del código;
- optimice-regex es un complemento divertido que ofrece consejos para mejorar las expresiones regulares. No es muy útil, porque regexp tenemos un poco. Pero lejos de todo posee magia regexp. Por lo tanto, es útil, pero no hay muchas preguntas;
- sonarjs es un complemento de fuego con comprobaciones de la complejidad del código y errores de refactorización típicos. Lo primero es curioso: el complemento evalúa la complejidad percibida del código y da consejos cuando vale la pena simplificar el código. La búsqueda de errores de refactorización a menudo también permite simplificar el código o, al menos, mejorar la legibilidad;
- @ typescript-eslint: reglas de eslint para verificar el código TypeScript. Y un conjunto para deshabilitar reglas básicas que no son compatibles con TS.
Nuestro archivo de reglas completo está
aquí . Observo que no es un dogma y se actualiza a medida que se adapta a los proyectos.