Jusqu'à récemment, dans tous les projets du front, les développeurs de Dodo Pizza Engineering utilisaient tslint - un outil utile qui vous indique quand vous avez
foiré le code, fait des inexactitudes, aide à maintenir le code dans le même style et corrige de nombreux commentaires. Mais alors tslint a pris et est mort. Sous la coupe, je vais vous dire pourquoi cela s'est produit, comment arrêter de verser des larmes sur le défunt et passer à l'outil eslint, et montrer également quelque chose de très intime.
En fait, tout a commencé il y a longtemps: la dernière version du noyau tslint était déjà en 2016. Et c'est le moment où il est temps de commencer à dire «dernier», si quelqu'un dit encore «dernier», car cette version était vraiment la dernière. Le 19 février 2019, un article
officiel a été publié pour arrêter le développement de tslint. Dans ce document, la société de développement (d'ailleurs, ce n'est même pas Microsoft) conseille vivement à tout le monde de passer à eslint, car leurs efforts viseront désormais à améliorer la prise en charge de TypeScript dans ce linter.
Une langue, une pile, une communauté
Microsoft considère TypeScript comme le principal langage de développement Web, qui devrait remplacer Java / ECMA Script. De toute évidence, un objectif aussi ambitieux implique une seule pile d'outils pour l'ensemble du développement frontal. Cela devrait grandement simplifier la migration de la grande communauté JS vers TypeScript. En plus de la garantie de confiance de Microsoft, eslint a une meilleure architecture que tslint. Par exemple, vous pouvez connecter des analyseurs et il y a plus de choix de règles connectées.
Microsoft ne serait pas lui-même s'il le voulait. Quoi que nous disions sur la qualité de leurs logiciels, ils font d'excellents outils de développement (et, en passant, des périphériques d'entrée). Cette fois, ils ne sont donc pas venus les mains vides, mais ont rédigé
un plan de migration . Conformément à ce plan, l'élaboration des règles tslint a déjà été interrompue le 1er août 2019 et le développement de tslint lui-même cessera le 1er novembre 2019. Bien que, pour être honnête, le développement ait été interrompu depuis longtemps (voir ci-dessus pour la dernière version).
Ici, il devrait devenir évident pour le lecteur qu'il est temps de passer à eslint, il n'y a pas d'autre choix. Pour sucrer la pilule, il convient de dire que:
- tandis que tslint se concentre sur TypeScript en mettant davantage l'accent sur l'utilisation correcte des types et la vérification de la syntaxe, eslint couvre tout ce qui peut être à l'avant, y compris la syntaxe des composants React;
- eslint a beaucoup plus de règles prédéfinies;
- il existe des règles (et plugins) qui vérifient le code au niveau du bloc (duplication de code, complexité perçue, etc.);
- il existe des plugins qui ne vérifient pas du tout le code, mais, par exemple, les expressions régulières.
En général, il semble que la transition vers un nouveau linter, qui est un produit traditionnel, nous ouvrira tout un monde d'opportunités inédites. Eh bien, essayons!
Ajouter eslint au projet
Je vais parler de la migration des règles ci-dessous. En attendant, configurez un projet pour travailler avec eslint.
Si vous avez déjà un projet avec tslint, supprimez d'abord tous les packages liés à tslint: tslint lui-même, tslint-react, tslint-config-prettier, etc.
Ajoutez maintenant des packages eslint au projet (définissez tout comme devDependencies):
- se scintiller;
- @ typescript-eslint / parser - moteur pour analyser TypeScript;
- @ typescript-eslint / eslint-plugin - jeux de règles pour TypeScript
Configuration minimale Eslint
Créez le fichier de configuration .eslintrc.json. Eslint prend en charge de nombreux formats de fichiers pour sa configuration, mais JSON semble le plus pratique. Voici à quoi ressemble l'option de travail minimale:
{ // "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 section
env indique à eslint les options de votre projet. Dans mon exemple, il s'agit d'un projet pour le navigateur (c'est-à-dire que le code fonctionnera dans le navigateur). Écrire pour Node.JS - définir le nœud: vrai. Les deux options suivantes indiquent le dialecte du JS en cours de test. En général, nous vérifierons le code pour TypeScript, mais si votre projet contient également du code pour JS, n'oubliez pas de les resserrer. Pour nous-mêmes, nous avons décidé de définir ces paramètres sur la même valeur que target dans tsconfig.json.
Il n'y a rien de controversé dans les ensembles de règles eslint standard, comme le point-virgule requis à la fin des expressions ou des espaces / tabulations. Toutes les règles sont particulièrement utiles. Vous pouvez voir quelles règles et avec quel niveau sont inclus
ici .
La ligne suivante, vous devez
désactiver la moitié des règles. Cela est nécessaire car ils ne fonctionnent pas avec TypeScript et au lieu de fonctionner normalement, ils génèrent un tas d'erreurs.
Ensuite, vous devez connecter les règles recommandées de TypeScript dans un sac séparé. Ici, vous devez garder à l'esprit que
les règles de syntaxe générales (telles que l'interdiction de var) fonctionneront ainsi.
Mais pour les règles qui
utilisent des types TS (par exemple, @ typescript-eslint / no-inutile-type-assertion), le moteur TypeScript est nécessaire. Et le moteur aura besoin du fichier tsconfig.json, dont le chemin doit être spécifié.
Dans tsconfig.json, chez Dodo Pizza Engineering, nous spécifions généralement les tests d'exclusion et de rejet afin qu'ils ne soient pas construits avec le projet. Mais pour qu'eslint fonctionne, vous devez spécifier et inclure. Autrement dit, tous les fichiers qui doivent être lintés doivent être explicitement inclus dans le projet. Sans cela, eslint jurera à chaque fichier qu'il trouve: "Le fichier n'est pas dans le projet, je ne ferai rien, je lancerai un tas d'erreurs." Il existe une option sans spécifier explicitement les fichiers de projet - définissez le paramètre
createDefaultProgram: true . Cela signifie essentiellement: "Tout ce que vous trouvez est Parsi." Mais les développeurs déconseillent fortement de le faire en raison d'une baisse significative des performances.
Si vous utilisez ForkTsCheckerWebpackPlugin pour traiter les fichiers TypeScript, remplacez
tslint: true par
eslint: true dans ses paramètres (dans webpack.config.ts).
Il vaut également la peine de configurer le lancement du linter à partir de la ligne de commande. Avant cela, ajoutez cette valeur à la section des scripts dans
package.json :
"eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json",
La première ligne commence juste la vérification eslint sans construire le projet. La seconde affiche les paramètres eslint actuels, ce qui vous permet de voir les paramètres des paramètres de règle.
Dans cette version, eslint fonctionnera déjà dans le projet et attrapera même des bancs: redéfinition des globales, variables inutilisées, etc.
Configuration du code Visual Studio
Après avoir parcouru tout ce chemin, vous pouvez déjà démarrer le linter à partir de la ligne de commande. Il sera également implicitement lancé lors de la construction du projet. Mais dans Visual Studio Code, nous ne verrons pas les commentaires du linter. Comment ça?!
Il existe un plugin eslint pour le studio (dbaeumer.vscode-eslint), il doit être installé. Après cela, rien ne fonctionnera de toute façon, rien ne sera souligné et corrigé. Pourquoi? Parce que le plugin a une configuration, qui dit que vous devez travailler uniquement dans des fichiers JavaScript.
Ce paramètre sournois n'est pas fait dans l'interface utilisateur, vous devez donc aller dans le fichier de paramètres du studio et ajouter manuellement les langues dont vous avez besoin au paramètre eslint.validate. Une liste complète des langues peut être trouvée dans les entrailles de la documentation du studio. Voici à quoi ressemble ce paramètre avec nous:
"eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ],
Après cela, redémarrez le studio et tout commencera enfin à fonctionner.
Reste maintenant à configurer les règles
Le projet est mis en place. Maintenant sur les règles, car dans l'exemple ci-dessus la liste des règles était vide.
Je dois dire que tslint ne nous a pas empêchés de gâcher dans un code formellement correct. Par exemple, oubliez attendre. Eslint est capable de trouver de telles erreurs sémantiques et de le jurer: informer que la valeur de retour est Promise, mais pour cela, pour une raison quelconque, l'attente n'est pas écrite. Cela inclut également des problèmes stylistiques de complexité moyenne: l'utilisation d'une lambda ou d'une fonction, etc., ce que Prettier ne peut plus faire.
Concernant les règles simples: position des crochets, tabulations vs. espaces, etc., on pense qu'ils devraient être donnés à Prettier ou à un paquet similaire. Mais dans le linter, ils doivent être laissés de toute façon: c'est la dernière frontière, qui est toujours en mesure d'arrêter le développeur négligent de l'ensemble de projet déchu. De plus, cette ligne peut être automatisée: par exemple,
husky , vous permet de démarrer le linter automatiquement pour chaque commit.
Nous avons décidé de
ne migrer aucun des ensembles de règles tslint que nous avons. Et créez votre propre ensemble à partir de zéro.
Il existe des jeux de règles prédéfinis pour eslint:
- ESLint Recommended est un ensemble de règles neutres conçu avec l'idée de ne pas engendrer d'holivars. Seuls les contrôles évidemment nécessaires sont inclus: variables non utilisées, etc. Tous les ensembles suivants prolongent celui-ci.
- Google - il y a déjà une raison pour holivar: pour l'indentation il y a strictement des espaces, un point-virgule est requis.
- AirBnB - Il existe également des règles de style strictes, y compris un point-virgule obligatoire.
- Standart - les points-virgules sont interdits ici, mais les virgules de fin sont également interdites.
Nous n'avons aimé aucun des forfaits prêts à l'emploi. Cela peut sembler étrange, mais il est important pour nous de passer à un nouveau linter, en évitant les guerres stylistiques. Si nous écrivons comme ça partout (tabulations, sans point-virgule, les virgules de fin sont obligatoires), alors laissez-le rester - l'essentiel est qu'il en soit de même dans tous les projets.
Sexe promis: son propre ensemble de règles
Honnêtement, pour montrer votre jeu de règles eslint, c'est comme une fille montrant des seins: il n'y a plus de secrets. J'ai longtemps pensé si cela valait la peine. Mais, après avoir consulté d'autres filles, j'ai décidé que cela en valait la peine.
Je vais commencer par les plugins que nous utilisons:
- react - vérifie le code du composant react. Ensemble de règles de base plus le nôtre. De l'important: nous nous noyons pour les composants fonctionnels purs;
- react-hooks - règles des développeurs de react concernant l'utilisation des hooks;
- promise - vérifie les erreurs courantes lors de l'utilisation de Promise. Cela fonctionne un peu bizarrement avec le code TypeScript. De l'important: nous essayons d'utiliser Promise partout et de ne pas utiliser de callbacks puis / catch en raison d'une meilleure lisibilité du code;
- Optimiser-regex est un plugin amusant qui donne des conseils sur l'amélioration des expressions régulières. Pas très utile, car regexp nous en avons un peu. Mais loin de tout posséder la magie regexp. C'est donc utile, mais il n'y a pas grand-chose à demander;
- sonarjs est un plug-in d'incendie qui vérifie la complexité du code et les erreurs de refactorisation typiques. Le premier est drôle: le plugin évalue la complexité perçue du code et donne des conseils quand cela vaut la peine de simplifier le code. La recherche d'erreurs de refactoring permet aussi souvent de simplifier le code ou, au moins, d'améliorer la lisibilité;
- @ typescript-eslint - règles eslint pour vérifier le code TypeScript. Et un ensemble pour désactiver les règles de base qui ne sont pas compatibles avec TS.
Notre fichier de règles complet est
ici . Je note que ce n'est pas un dogme et est mis à jour car il s'adapte aux projets.