👨🏼‍⚖️ 🙇 ⏺️ Prettier, ESLint, Husky, Lint-Staged et EditorConfig: outils pour écrire du code ordonné 😄 👩‍🔬 🕢

Vous vous efforcez d'écrire du code soigné, mais vous ne savez pas par où commencer ... Vous lisez les guides de style, comme celui d'Airbnb, essayez de suivre les recommandations pratiques des meilleurs experts ... Devez-vous supprimer le code inutilisé? Vous devez rechercher des variables inutiles? Essayez-vous d'identifier les mauvais schémas utilisés dans vos programmes? Par exemple - vous voulez comprendre, en lisant les subtilités du code d'une certaine fonction, s'il retournera quelque chose ou non. Cela vous semble familier? Le problème est qu'il est très difficile pour un programmeur de faire beaucoup et d'apprendre beaucoup.

Peut-être êtes-vous un chef d'équipe sous la direction duquel travaille une équipe de développeurs de différents niveaux? Y a-t-il de nouvelles personnes dans votre équipe? Cela vous dérange-t-il que le code qu'ils écrivent ne réponde pas à vos normes? Vos journées passent-elles par des tests de code d'autrui, lorsque ces contrôles concernent principalement le respect des normes, et non la logique du programme?

L'auteur de ce document dit qu'il était confronté à tout ce que les questions qui viennent d'être posées lui sont consacrées. Ce à quoi il est confronté est fatigant et épuisant. Ici, il veut parler d'outils, dont l'application correcte nous permet de résoudre les problèmes ci-dessus.

À savoir, nous parlerons ici d'outils tels que Prettier, ESLint, Husky, Lint-Staged, EditorConfig et de l'automatisation du formatage et du linting de code. Ce matériel est principalement axé sur le développement de React, mais les principes discutés ici peuvent être appliqués dans n'importe quel projet Web. Voici un référentiel où, entre autres, ce qui est discuté ici est compilé.

Plus joli

Prettier est un outil de formatage de code qui vise à utiliser des règles codées en dur pour concevoir des programmes. Il formate le code automatiquement. Voici à quoi ça ressemble.

Prettier formate le code en suivant les règles

▍ Les points forts de Prettier

Voici les fonctionnalités et fonctionnalités de Prettier qui nous permettent de parler de l'utilité de cet outil:

Ranger la base de code existante. En utilisant Prettier, vous pouvez le faire littéralement avec une seule commande. Le traitement manuel de grandes quantités de code prendra beaucoup plus de temps. Imaginez, par exemple, le travail requis pour formater manuellement 20 000 lignes de code.
Prettier est facile à mettre en œuvre. Prettier utilise l'approche «moyenne» et la moins controversée du style lors du formatage du code. Depuis que le projet est open source, beaucoup y ont contribué, en l'améliorant et en adoucissant les angles vifs.
Prettier vous permet de vous concentrer sur l'écriture de code, pas sur son formatage. Beaucoup ne réalisent tout simplement pas combien de temps et d'efforts sont consacrés à la mise en forme du code. L'utilisation de Prettier vous permet de ne pas penser au formatage, mais de faire de la programmation à la place. Dans mon cas, par exemple, l'efficacité du travail, grâce à Prettier, a augmenté de 10%.
Prettier aide les débutants. Si vous êtes un programmeur débutant travaillant dans la même équipe avec des professionnels sérieux et que vous voulez avoir l'air digne de leur expérience, Prettier vous aidera.

▍Configuration de Prettier

Voici comment utiliser Prettier dans un nouveau projet. Créez le dossier d' app et accédez-y, exécutez la commande suivante sur la ligne de commande:

 npm init -y

Grâce à cette commande, npm initialise un nouveau projet dans le dossier app en y créant le fichier package.json .

Dans ce matériau, j'utiliserai du yarn , mais ici, vous pouvez utiliser npm . Prettier peut également être connecté à un projet existant.

Installez le prettier package en tant que dépendance de développement de notre projet:

 yarn add --dev prettier

Grâce à cette commande, une entrée de dépendance de package.json sera ajoutée à package.json qui ressemble à ceci:

 { "name": "react-boiler-plate", "version": "1.0.0", "description": "A react boiler plate", "main": "src/index.js", "author": "Adeel Imran", "license": "MIT", "scripts": {   "prettier": "prettier --write src/**/*.js" }, "devDependencies": {   "prettier": "^1.14.3" } }

Nous parlerons de ce que signifie la ligne la "prettier": "prettier — write src/**/*.js" peu plus loin. En attendant, créez le dossier src dans le dossier de l' app . Dans ce dossier, créez le fichier index.js , bien que vous puissiez le nommer comme bon vous semble.

Nous allons ajouter le code suivant à ce fichier (sous cette forme disgracieuse):

 let person =                     { name: "Yoda",               designation: 'Jedi Master '               };             function trainJedi (jediWarrion) { if (jediWarrion.name === 'Yoda') { console.log('No need! already trained'); } console.log(`Training ${jediWarrion.name} complete`)             } trainJedi(person)             trainJedi({ name: 'Adeel',             designation: 'padawan' });

Donc, pour le moment, nous avons le src/app/index.js , qui contient un code assez mal conçu.

Comment y remédier? Il existe trois approches pour travailler avec du code mal formaté:

Formatez manuellement ce code.
Utilisez un outil automatisé.
Laissez-le tel quel et travaillez (je vous demande de ne pas choisir cette approche).

Je vais choisir la deuxième option. Maintenant, dans notre projet, il existe une dépendance correspondante et, en outre, dans la section scripts du fichier package.json , il existe un enregistrement sur Prettier. Il est clair que nous utiliserons cet outil pour formater le code. Pour ce faire, créez le fichier prettier.config.js dans le dossier de l' app et ajoutez-y les règles pour Prettier:

 module.exports = { printWidth: 100, singleQuote: true, trailingComma: 'all', bracketSpacing: true, jsxBracketSameLine: false, tabWidth: 2, semi: true, };

Analysons ces règles:

printWidth: 100 - la longueur de la ligne ne doit pas dépasser 100 caractères.
singleQuote: true - tous les guillemets doubles seront convertis en guillemets simples. Voir le Guide de style Airbnb pour plus de détails. J'aime beaucoup ce guide, je l'utilise pour améliorer la qualité de mon code.
trailingComma: 'all' - fournit une virgule après la dernière propriété de l'objet. Voici un bon article sur ce sujet.
bracketSpacing: true - responsable de l'insertion d'espaces entre le corps de l'objet et les accolades dans les littéraux d'objet. Si cette propriété est définie sur true , les objets déclarés à l'aide de littéraux d'objets ressembleront à ceci: { foo: bar } . Si vous le définissez sur false , de telles constructions ressembleront à ceci: {foo: bar} .
jsxBracketSameLine: false - grâce à cette règle, le symbole > dans les éléments JSX multilignes sera placé sur la dernière ligne. Voici à quoi ressemble le code si cette règle est définie sur true :

 <button className="prettier-class" id="prettier-id" onClick={this.handleClick}> Click Here </button>

Voici ce qui se passe s'il est défini sur false :

 <button className="prettier-class" id="prettier-id" onClick={this.handleClick} > Click Here </button>

tabWidth: 2 - définit le nombre d'espaces par niveau d'alignement.
semi: true - si cette règle est définie sur true , un point-virgule est ajouté à la fin des expressions.

Retrouvez toutes les règles Prettier ici.

Maintenant que les règles sont configurées, parlons de ce script:

 "prettier": "prettier  — write src/**/*.js"

Grâce à cette conception, Prettier se lance et trouve tous les fichiers .js dans le dossier src . L'indicateur --write lui dit d'enregistrer les fichiers formatés au fur et à mesure qu'ils sont traités et corrige les erreurs de formatage qui s'y trouvent.

Exécutez le script à partir de la ligne de commande:

 yarn prettier

C'est ce qui s'est passé après cela avec le code mal formaté montré ci-dessus.

Résultat du formatage du code avec Prettier

Sur ce, nous supposerons qu'avec Prettier nous avons compris. Parlons des linters.

ESLint

Le linting est un type d'analyse de code statique qui est souvent utilisé pour trouver des modèles de conception problématiques ou du code qui ne suit pas certaines directives de style.

Il existe des linters conçus pour la plupart des langages de programmation, parfois les compilateurs incluent le linting dans le processus de compilation du code. Cette définition du peluchage est tirée de la page d' informations open source pour le JavaScript ESLint JavaScript open source, dont nous parlerons.

▍Pourquoi ai-je besoin d'un linter pour JavaScript?

Étant donné que JavaScript est un langage de programmation dynamique avec un typage faible, le code écrit est sujet aux erreurs commises par les développeurs. JavaScript est un langage interprété, donc la syntaxe et d'autres erreurs dans le code ne sont généralement détectées qu'après l'exécution de ce code.

Les linters, comme ESLint , permettent aux développeurs de trouver des problèmes dans le code sans le démarrer.

▍Pourquoi ESLint est-il un outil spécial?

Une bonne question a été posée dans le titre de cette section. Le point ici est que ESLint prend en charge les plugins. Ainsi, les règles de vérification de code ne doivent pas être un package monolithique. Tout ce dont vous avez besoin peut être connecté au besoin. Chaque règle de charpie ajoutée au système est autonome, elle peut être activée ou désactivée, indépendamment des autres. Chaque règle peut se voir attribuer un niveau d'alerte conformément au souhait du développeur - il peut s'agir d'un avertissement (avertissement) ou d'une erreur (erreur).

Lorsque vous utilisez ESLint, vous travaillez avec un système entièrement personnalisable qui peut refléter votre compréhension de ce à quoi devrait ressembler le code correct et capturer l'ensemble de règles que vous suivez.

Parmi les guides de style JavaScript existants, les suivants sont très populaires:

Comme je l'ai déjà mentionné, j'utilise le guide de style Airbnb. J'ai été conseillé par ce document par mon manager dans l'entreprise où ma carrière professionnelle a commencé, et je considère ce guide de style comme mon atout le plus précieux.

Ce guide est activement maintenu - jetez un œil à son référentiel sur GitHub. Ici, je vais utiliser un ensemble de règles basées sur lui.

Maintenant, travaillons sur le fichier package.json , ajoutez-y quelques dépendances:

 { "name": "react-boiler-plate", "version": "1.0.0", "description": "A react boiler plate", "main": "src/index.js", "author": "Adeel Imran", "license": "MIT", "scripts": {   "lint": "eslint --debug src/",   "lint:write": "eslint --debug src/ --fix",   "prettier": "prettier --write src/**/*.js" }, "husky": {   "hooks": {     "pre-commit": "lint-staged"   } }, "lint-staged": {   "*.(js|jsx)": ["npm run lint:write", "git add"] }, "devDependencies": {   "babel-eslint": "^8.2.3",   "eslint": "^4.19.1",   "eslint-config-airbnb": "^17.0.0",   "eslint-config-jest-enzyme": "^6.0.2",   "eslint-plugin-babel": "^5.1.0",   "eslint-plugin-import": "^2.12.0",   "eslint-plugin-jest": "^21.18.0",   "eslint-plugin-jsx-a11y": "^6.0.3",   "eslint-plugin-prettier": "^2.6.0",   "eslint-plugin-react": "^7.9.1",   "husky": "^1.1.2",   "lint-staged": "^7.3.0",   "prettier": "^1.14.3" } }

Avant de parler de la façon de travailler avec cette configuration, je veux m'attarder sur les dépendances du projet qui sont ajoutées à package.json . Je crois qu'avant d'utiliser certaines dépendances, vous devez savoir quel rôle elles jouent.

Par conséquent, nous discuterons du rôle des packages présentés ici:

babel-eslint - vous permet d'utiliser le peluchage pour appliquer à tout ce que Babel donne. Vous n'avez pas besoin de ce plugin si vous n'utilisez pas Flow ou des fonctionnalités expérimentales qu'ESLint ne prend pas encore en charge.
eslint est le principal outil utilisé pour coder le code.
eslint-config-airbnb - Fournit des règles Airbnb en tant que configuration pouvant être modifiée.
eslint-plugin-babel est un plugin ESLint qui complète le babel-eslint . Il a repensé les règles qui, lors de l'utilisation de babel-eslint , posent des problèmes lors du traitement des fonctionnalités expérimentales.
eslint-plugin-import - ce paquet prend en charge la liaison de nouvelles constructions de syntaxe d' import/export et aide à prévenir les problèmes associés à une orthographe incorrecte des chemins de fichiers et des noms des modules importés.
eslint-plugin-jsx-a11y - fournit des règles concernant la disponibilité des éléments JSX pour les personnes handicapées. L'accessibilité du Web est très importante.
eslint-plugin-prettier - Aide ESLint et Prettier à travailler ensemble. Cela ressemble à ceci: lorsque Prettier formate le code, il le fait en tenant compte des règles ESLint.
eslint-plugin-react - contient des règles ESLint conçues pour React.

Dans cet article, nous ne parlons pas de test de code, mais dans le package.json ci-dessus, il existe des dépendances conçues pour les tests unitaires à l'aide de Jest / Enzyme . Maintenant, si vous décidez d'utiliser ces outils pour les tests, une description des packages concernés.

eslint-config-jest-enzyme - ce package est destiné aux cas où vous utilisez jest-environment-enzyme , ce qui conduit au fait que les variables React et Enzyme sont globales. Grâce à cela, ESLint n'émettra pas d'avertissements sur ces variables.
eslint-plugin-jest — Plugin ESlint pour Jest.

Il y a quelques autres packages dans le fichier que nous discuterons plus tard, en discutant des problèmes d'automatisation. C'est husky et lint-staged .

Maintenant que nous avons, en termes généraux, discuté de nos outils, nous allons continuer à travailler.
Créez le fichier .eslintrc.js dans le dossier de l' app :

 module.exports = {   env: {       es6: true,       browser: true,       node: true,   },   extends: ['airbnb', 'plugin:jest/recommended', 'jest-enzyme'],   plugins: [       'babel',       'import',       'jsx-a11y',       'react',       'prettier',   ],   parser: 'babel-eslint',   parserOptions: {       ecmaVersion: 6,       sourceType: 'module',       ecmaFeatures: {           jsx: true       }   },   rules: {       'linebreak-style': 'off', //    Windows.       'arrow-parens': 'off', //   prettier       'object-curly-newline': 'off', //   prettier       'no-mixed-operators': 'off', //   prettier       'arrow-body-style': 'off', //  -   ?       'function-paren-newline': 'off', //   prettier       'no-plusplus': 'off',       'space-before-function-paren': 0, //   prettier       'max-len': ['error', 100, 2, { ignoreUrls: true, }], // airbnb           'no-console': 'error', // airbnb         'no-alert': 'error', // airbnb         'no-param-reassign': 'off', //  -   ?       "radix": "off", // parseInt, parseFloat  radix .    .       'react/require-default-props': 'off', // airbnb           'react/forbid-prop-types': 'off', // airbnb           'react/jsx-filename-extension': ['error', { extensions: ['.js'] }], // airbnb  .jsx       'prefer-destructuring': 'off',       'react/no-find-dom-node': 'off', //           'react/no-did-mount-set-state': 'off',       'react/no-unused-prop-types': 'off', //            'react/jsx-one-expression-per-line': 'off',       "jsx-a11y/anchor-is-valid": ["error", { "components": ["Link"], "specialLink": ["to"] }],       "jsx-a11y/label-has-for": [2, {           "required": {               "every": ["id"]           }       }], //     htmlFor  label       'prettier/prettier': ['error'],   }, };

Ajoutez maintenant le fichier .eslintignore dossier de l' app :

 /.git /.vscode node_modules

Parlons maintenant de la .eslintrc.js fichier .eslintrc.js et de la signification des constructions qui y sont présentées.

Ce fichier a la structure suivante:

 module.exports = {  env:{},  extends: {},  plugin: {},  parser: {},  parserOptions: {},  rules: {}, };

Considérez les blocs de ce fichier représentés par des objets avec les noms correspondants:

env - vous permet de spécifier une liste des environnements pour lesquels vous prévoyez de vérifier le code. Dans notre cas, les es6 , browser et node sont définies sur true . Le paramètre es6 inclut des fonctionnalités ES6, à l'exception des modules (cette fonctionnalité définit automatiquement, dans le bloc parserOptions , le paramètre ecmaVersion sur 6 ). Le paramètre de browser des variables de navigateur globales telles que Windows . Le paramètre node ajoute des variables d'environnement et des étendues globales Node.js, par exemple, global . Des détails sur les environnements peuvent être trouvés ici .
extends - est un tableau de lignes avec des configurations, avec chaque configuration supplémentaire étend la précédente. Les règles de airbnb Airbnb sont utilisées airbnb , qui sont développées en jest puis développées en jest-enzyme .
plugins - voici les règles de peluchage que nous voulons utiliser. Nous appliquons les règles babel , import , jsx-a11y , jsx-a11y , prettier , dont nous avons déjà parlé.
parser - ESLint utilise l' parser Espree par défaut, mais puisque nous travaillons avec Babel, nous devons utiliser Babel-ESLint .
parserOptions - puisque nous avons changé l'analyseur standard en babel-eslint , nous devons également définir les propriétés dans ce bloc. La propriété ecmaVersion définie sur 6 indique à ESLint que le code ES6 sera vérifié. Comme nous écrivons du code dans des modules EcmaScript , la propriété sourceType définie sur module . Et enfin, puisque nous utilisons React, ce qui signifie utiliser JSX, un objet avec la clé jsx définie sur true écrit dans la propriété ecmaFeatures .
rules - J'aime le plus cette partie du fichier .eslintrc.js car elle vous permet de configurer les règles ESLint. Toutes les règles que nous avons développées ou ajoutées à l'aide de plugins peuvent être modifiées ou redéfinies, et cela se fait dans le bloc de rules . Le texte du fichier contient des commentaires sur les règles.

Parlons .eslintignore fichier .eslintignore . Ce fichier accepte une liste de chemins représentant des dossiers dont le contenu ne doit pas être traité à l'aide d'ESLint.

Trois dossiers sont définis ici:

/.git - Je n'ai pas besoin d'ESLint pour vérifier les fichiers liés à Git.
/.vscode - le projet a ce dossier car j'utilise VS Code. Ici, l'éditeur stocke les informations de configuration qui peuvent être définies pour chaque projet. Ces données ne doivent pas non plus être traitées par le linter.
node-modules - les fichiers de dépendances n'ont pas non plus besoin d'être vérifiés avec un linter.

Voyons maintenant quelques nouveaux scripts apparus dans package.json . Les voici:

 "lint": "eslint --debug src/" "lint:write": "eslint --debug src/ --fix"

Si vous exécutez le premier d'entre eux, en utilisant la commande yarn lint ou npm run lint , le linter examinera tous les fichiers du répertoire src et affichera un rapport détaillé sur les fichiers dans lesquels il a trouvé des erreurs. À l'aide de ce rapport, vous pouvez corriger ces erreurs.

Exécution du script lint

Si vous exécutez le deuxième script ( yarn lint:write ), ESLint effectuera la même vérification que précédemment. La seule différence est que dans ce mode, le système essaiera de corriger les erreurs détectées, essayera d'amener le code sous la forme la plus décente possible.

Extension ESLint pour VS Code

Nous avons déjà configuré Prettier et ESLint, mais pour utiliser les capacités de ces outils, nous devons exécuter des scripts. Ce n'est pas très pratique, alors essayez de le réparer. À savoir, nous voulons nous assurer que le formatage et le peluchage du code sont effectués par la commande pour enregistrer le fichier dans l'éditeur. De plus, nous souhaitons effectuer le linting et le formatage du code avant de valider.

À titre d'exemple, nous utilisons l'éditeur VS Code. Nous aurons besoin de l'extension ESLint pour VS Code. Pour l'installer, vous pouvez ouvrir le panneau d'extension VS Code ( ctrl+shift+x ). Ici, dans le champ de recherche, entrez eslint . Une liste d'extensions apparaît. Ce qui nous intéresse est celui dont les informations pour les développeurs sont Dirk Baeumer. Après avoir installé cette extension, redémarrez l'éditeur.

Maintenant, dans le dossier racine du projet ( app ), créez le dossier .vscode (faites attention au point au début du nom - c'est important). Dans ce dossier, créez un fichier settings.json avec le contenu suivant:

 { "editor.formatOnSave": false, "eslint.autoFixOnSave": true, }

Considérez son contenu.

La propriété editor.formatOnSave définie sur false indique que nous n'avons pas besoin de la configuration standard pour appliquer au formatage de fichier, car cela peut provoquer un conflit avec ESLint et Prettier.
La propriété eslint.autoFixOnSave définie sur true , car il est nécessaire que le plug-in installé se déclenche chaque fois qu'un fichier est enregistré. Étant donné qu'ESLint et Prettier fonctionnent ensemble dans un projet, l'enregistrement du fichier entraîne à la fois le formatage et le linting de code.

Il est important de noter que maintenant, lorsque le script lint:write est exécuté, il effectuera à la fois le linting et le formatage du code.

Imaginez vos sentiments si vous obteniez un code de projet de 20 000 lignes que vous auriez besoin de vérifier et d'améliorer. Imaginez maintenant que vous deviez le faire manuellement. Un tel travail prendrait probablement un mois. Et à l'aide des outils d'automatisation ci-dessus, tout cela se fait en une trentaine de secondes.

Maintenant, après avoir configuré tout ce dont vous avez besoin, chaque fois que vous enregistrez le fichier avec le code, l'éditeur se chargera de vérifier et de formater le texte du programme. Cependant, nous parlons ici de l'éditeur VS Code. Il est possible qu'un membre de votre équipe préfère un autre éditeur. Il n'y a rien de mal à cela, mais pour que tout le monde puisse travailler plus facilement, nous devrons trouver autre chose à automatiser.

Husky

Le paquet Husky vous permet d'utiliser des crochets Git. Cela signifie que vous avez la possibilité d'effectuer certaines actions avant de valider ou d'envoyer le code du référentiel.

Afin de profiter des fonctionnalités de Husky, installez d'abord ce package:

 yarn add --dev husky

Après cela, ajoutez ce qui suit à package.json :

 "husky": {     "hooks": {         "pre-commit": "YOUR_COMMAND_HERE",    "pre-push": "YOUR_COMMAND_HERE"    } },

Cela conduira au fait qu'avant d'exécuter la commande commit ou push , un certain script sera appelé, qui, par exemple, effectue un test de code ou un formatage.

Des détails sur Husky peuvent être trouvés ici .

Lint-staged

Le package par étapes Lint vous permet de vérifier les fichiers indexés à l'aide du linter, ce qui permet d'éviter que des erreurs soient envoyées au référentiel.

Linting est logique avant de valider le code. Grâce à cela, vous pouvez vous assurer que les erreurs ne pénètrent pas dans le référentiel et fournir un style unifié du code qui y arrive. Cependant, linting pour vérifier l'ensemble du projet peut être une tâche trop longue, et les résultats d'une telle vérification peuvent être dénués de sens. En fin de compte, le peluchage peut avoir besoin d'exposer les fichiers que vous prévoyez de valider.

Lint-staged vous permet d'effectuer un ensemble de tâches arbitraires sur des fichiers indexés filtrés par un modèle de recherche. Des détails à ce sujet peuvent être trouvés ici .

Installez le package par étapes Lint:

 yarn add --dev lint-staged

Ensuite, dans le fichier package.json , ajoutez ce qui suit:

 "lint-staged": {     "*.(js|jsx)": ["npm run lint:write", "git add"] },

Grâce à cette construction, la commande lint:write sera exécutée en premier, vérifiant le contenu du fichier et corrigeant les erreurs, après quoi les fichiers seront ajoutés à l'index avec la commande git add . Maintenant, cette commande vise les fichiers .js et .jsx , mais la même chose peut être faite avec des fichiers d'autres types.

Partage Husky et Lint

Considérez un diagramme d'action qui vous permet d'organiser le prochain flux de travail. Chaque fois que vous validez des fichiers avec du code, avant d'effectuer cette opération, le système exécute le script lint-staged qui, à son tour, exécute le script lint:write , qui effectue le linting et le formatage du code. Après cela, les fichiers sont ajoutés à l'index puis validés. Il me semble que c'est très pratique. En fait, dans le code présenté précédemment du fichier package.json , cela est déjà implémenté, nous n'en avons tout simplement pas parlé auparavant.

Voici à nouveau le contenu de notre package.json :

 { "name": "react-boiler-plate", "version": "1.0.0", "description": "A react boiler plate", "main": "src/index.js", "author": "Adeel Imran", "license": "MIT", "scripts": {   "lint": "eslint --debug src/",   "lint:write": "eslint --debug src/ --fix",   "prettier": "prettier --write src/**/*.js" }, "husky": {   "hooks": {     "pre-commit": "lint-staged"   } }, "lint-staged": {   "*.(js|jsx)": ["npm run lint:write", "git add"] }, "devDependencies": {   "babel-eslint": "^8.2.3",   "eslint": "^4.19.1",   "eslint-config-airbnb": "^17.0.0",   "eslint-config-jest-enzyme": "^6.0.2",   "eslint-plugin-babel": "^5.1.0",   "eslint-plugin-import": "^2.12.0",   "eslint-plugin-jest": "^21.18.0",   "eslint-plugin-jsx-a11y": "^6.0.3",   "eslint-plugin-prettier": "^2.6.0",   "eslint-plugin-react": "^7.9.1",   "husky": "^1.1.2",   "lint-staged": "^7.3.0",   "prettier": "^1.14.3" } }

Maintenant que vous connaissez Husky et Lint-Staged, vous pouvez évaluer leur impact sur le travail avec Git. À savoir, supposons que les commandes suivantes ont été exécutées:

 $ git add . $ git commit -m "some descriptive message here"

Il est clair qu'avant de s'engager, le code sera vérifié pour la conformité avec les règles spécifiées dans .eslintrc.js et, si nécessaire, corrigé. Grâce à cela, les erreurs n'entreront jamais dans le référentiel d'un projet en cours.

Vous savez maintenant comment intégrer Prettier, ESLint, Husky et Lint-staged dans votre projet.

Permettez-moi de vous rappeler que nous avons dit ci-dessus que tous les membres de votre équipe n'utilisent pas mon code VS préféré. Pour que tous fonctionnent .editorconfig , nous devons traiter le fichier .editorconfig .

Fichier .Editorconfig

Différents membres de votre équipe peuvent utiliser différents éditeurs. Les forçant à utiliser n'importe quel éditeur pour quoi que ce soit. Cependant, pour que tout le monde utilise les mêmes paramètres, concernant par exemple les retraits ou les sauts de ligne, nous utilisons le fichier. editorconfig .Il permet de maintenir un ensemble uniforme de règles dans des équipes hétérogènes.

Sur le site Web du projet, vous pouvez trouver une liste des éditeurs qui prennent en charge ce fichier. En particulier, il comprend WebStorm, AppCode, Atom, Eclipse, Emacs, BBEdit et autres.

Créez un fichier dans le dossier de appnotre projet .editorconfiget ajoutez-y le code suivant:

 # EditorConfig -  : http://EditorConfig.org #  EditorConfig   root = true [*.md] trim_trailing_whitespace = false [*.js] trim_trailing_whitespace = true #     Unix       [*] indent_style = space indent_size = 2 end_of_line = lf charset = utf-8 insert_final_newline = true max_line_length = 100

Expliquons les paramètres utilisés dans ce fichier:

trim_trailing_whitespace = false- la suppression des espaces à la fin des lignes dans les .mdfichiers n'est pas effectuée. Une option similaire pour .js-files est définie sur false.
indent_style = space - les retraits sont faits d'espaces et non de tabulations.
indent_size = 2 - la taille du tiret est de deux espaces.
end_of_line = lf — lf . , , . .
insert_final_newline = true — .
max_line_length = 100 — 100 .

Résumé

, , , . , , .

Chers lecteurs! ? ?

Prettier, ESLint, Husky, Lint-Staged et EditorConfig: outils pour écrire du code ordonné