Sie möchten sauberen Code schreiben, wissen aber nicht, wo Sie anfangen sollen ... Sie lesen die Styleguides wie 
diese von Airbnb und versuchen, den praktischen Empfehlungen führender Experten zu folgen ... Müssen Sie nicht verwendeten Code löschen? Müssen Sie nach unnötigen Variablen suchen? Versuchen Sie, schlechte Muster zu identifizieren, die in Ihren Programmen verwendet werden? Zum Beispiel - Sie möchten verstehen, indem Sie die Feinheiten des Codes einer bestimmten Funktion lesen, ob sie etwas zurückgibt oder nicht. Kommt Ihnen das bekannt vor? Das Problem ist, dass es für einen Programmierer sehr schwierig ist, viel zu tun und viel zu lernen.
Vielleicht sind Sie ein Teamleiter, unter dessen Führung ein Team von Entwicklern verschiedener Ebenen arbeitet? Gibt es neue Leute in Ihrem Team? Stört es Sie, dass der von ihnen geschriebene Code nicht Ihren Standards entspricht? Vergehen Ihre Tage bei Tests des Codes anderer Personen, wenn diese Überprüfungen hauptsächlich die Einhaltung von Standards und nicht die Programmlogik betreffen?

Der Autor dieses Materials sagt, dass er mit allem konfrontiert war, dem die gerade gestellten Fragen gewidmet sind. Was ihm bevorsteht, ist anstrengend und anstrengend. Hier möchte er über Werkzeuge sprechen, deren korrekte Anwendung es uns ermöglicht, die oben genannten Probleme zu lösen.
Wir werden hier nämlich über Tools wie Prettier, ESLint, Husky, Lint-Staged, EditorConfig und über die Automatisierung von Formatierung und Code-Flusen sprechen. Dieses Material konzentriert sich hauptsächlich auf die React-Entwicklung, aber die hier diskutierten Prinzipien können in jedem Webprojekt angewendet werden. 
Hier ist ein Repository, in dem unter anderem zusammengestellt wird, was hier besprochen wird.
Schöner
Prettier ist ein Code-Formatierungswerkzeug, das fest codierte Regeln zum Entwerfen von Programmen verwenden soll. Der Code wird automatisch formatiert. So sieht es aus.
Hübscher formatiert den Code gemäß den Regeln▍ Stärken schöner
Hier sind die Funktionen von Prettier, mit denen wir über die Nützlichkeit dieses Tools sprechen können:
- Aufräumen der vorhandenen Codebasis. Mit Prettier können Sie dies buchstäblich mit nur einem Befehl tun. Die manuelle Verarbeitung großer Codemengen nimmt viel mehr Zeit in Anspruch. Stellen Sie sich zum Beispiel die Arbeit vor, die erforderlich ist, um 20.000 Codezeilen manuell zu formatieren.
- Schöner ist einfach zu implementieren. Hübscher verwendet beim Formatieren von Code den „durchschnittlichen“, am wenigsten kontroversen Ansatz für den Stil. Da das Projekt Open Source ist, haben viele dazu beigetragen, es verbessert und scharfe Ecken geglättet.
- Mit Prettier können Sie sich darauf konzentrieren, Code zu schreiben, nicht ihn zu formatieren. Viele wissen einfach nicht, wie viel Zeit und Mühe für die Formatierung des Codes aufgewendet wird. Mit Prettier können Sie nicht über die Formatierung nachdenken, sondern stattdessen programmieren. In meinem Fall beispielsweise stieg die Arbeitseffizienz dank Prettier um 10%.
- Schöner hilft Anfängern. Wenn Sie ein Anfängerprogrammierer sind, der mit seriösen Fachleuten im selben Team arbeitet, und vor ihrem Hintergrund würdig aussehen möchten, hilft Ihnen Prettier dabei.
▍Konfigurieren hübscher
Hier erfahren Sie, wie Sie Prettier in einem neuen Projekt verwenden. Erstellen Sie den 
app Ordner, und führen Sie den folgenden Befehl in der Befehlszeile aus:
 npm init -y 
Dank dieses Befehls initialisiert 
npm ein neues Projekt im 
app Ordner, indem die Datei 
package.json darin erstellt wird.
Ich werde in diesem Material 
yarn , aber hier können Sie 
npm . Schöner kann auch mit einem bestehenden Projekt verbunden werden.
Installieren Sie das 
prettier Paket als Entwicklungsabhängigkeit unseres Projekts:
 yarn add  
Dank dieses Befehls wird 
package.json hinzugefügt, der 
package.json aussieht:
 { "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" } } 
Wir werden etwas später darüber sprechen, was die 
"prettier": "prettier — write src/**/*.js" Zeile bedeutet 
"prettier": "prettier — write src/**/*.js" . Erstellen Sie in der Zwischenzeit den Ordner 
src im 
app Ordner. Erstellen Sie in diesem Ordner die Datei 
index.js , obwohl Sie sie beliebig benennen können.
Wir werden dieser Datei den folgenden Code hinzufügen (in dieser unansehnlichen Form):
 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' }); 
Im Moment haben wir also die 
src/app/index.js , die einen ziemlich schlecht gestalteten Code enthält.
Wie kann ich das beheben? Es gibt drei Ansätze, um mit schlecht formatiertem Code zu arbeiten:
- Formatieren Sie diesen Code manuell.
- Verwenden Sie ein automatisiertes Tool.
- Lass es wie es ist und arbeite daran (ich bitte dich, diesen Ansatz nicht zu wählen).
Ich werde die zweite Option wählen. In unserem Projekt gibt es jetzt eine entsprechende Abhängigkeit, und außerdem gibt es im 
package.json Datei 
package.json einen Datensatz über Prettier. Es ist klar, dass wir dieses Tool verwenden werden, um den Code zu formatieren. Erstellen Sie dazu die Datei 
prettier.config.js im 
app Ordner und fügen Sie dort die Regeln für Prettier hinzu:
 module.exports = { printWidth: 100, singleQuote: true, trailingComma: 'all', bracketSpacing: true, jsxBracketSameLine: false, tabWidth: 2, semi: true, }; 
Lassen Sie uns diese Regeln analysieren:
- printWidth: 100- Die Zeilenlänge sollte 100 Zeichen nicht überschreiten.
- singleQuote: true- Alle doppelten Anführungszeichen werden in einfache Anführungszeichen konvertiert. Weitere Informationen finden Sie im Airbnb Style Guide . Ich mag diesen Leitfaden sehr, ich benutze ihn, um die Qualität meines Codes zu verbessern.
- trailingComma: 'all'- Gibt ein Komma nach der letzten Eigenschaft des Objekts an. Hier ist ein guter Artikel zu diesem Thema.
- bracketSpacing: true- ist für das Einfügen von Leerzeichen zwischen dem- bracketSpacing: trueund geschweiften Klammern in Objektliteralen verantwortlich. Wenn diese Eigenschaft auf- true, sehen Objekte, die mit Objektliteralen deklariert wurden, folgendermaßen aus:- { foo: bar }. Wenn Sie den Wert auf- false, sehen solche Konstruktionen folgendermaßen aus:- {foo: bar}.
- jsxBracketSameLine: false- Dank dieser Regel wird das Symbol- >in mehrzeiligen JSX-Elementen in der letzten Zeile platziert. So sieht der Code aus, wenn diese Regel auf- true:
 <button className="prettier-class" id="prettier-id" onClick={this.handleClick}> Click Here </button> 
Folgendes passiert, wenn es auf 
false :
 <button className="prettier-class" id="prettier-id" onClick={this.handleClick} > Click Here </button> 
- tabWidth: 2-- tabWidth: 2die Anzahl der Leerzeichen pro Ausrichtungsebene fest.
- semi: true- Wenn diese Regel auf- true, wird am Ende der Ausdrücke ein Semikolon hinzugefügt.
Hier finden Sie alle schöneren Regeln.
Nachdem die Regeln konfiguriert sind, sprechen wir über dieses Skript:
 "prettier": "prettier  — write src/**/*.js" 
Dank dieses Designs startet Prettier alle 
.js Dateien und findet 
.js im 
src Ordner. Das Flag 
--write weist ihn an, formatierte Dateien während der Verarbeitung zu speichern und die darin enthaltenen Formatierungsfehler zu korrigieren.
Führen Sie das Skript über die Befehlszeile aus:
 yarn prettier 
Dies geschah danach mit dem oben gezeigten schlecht formatierten Code.
Ergebnis der Formatierung des Codes mit PrettierIn diesem Zusammenhang gehen wir davon aus, dass wir es mit Prettier herausgefunden haben. Sprechen wir über Linters.
ESLint
Flusen ist eine Art statischer Code-Analyse, die häufig verwendet wird, um problematische Entwurfsmuster oder Code zu finden, die bestimmten Stilrichtlinien nicht entsprechen.
Es gibt Linters, die für die meisten Programmiersprachen entwickelt wurden. Manchmal schließen Compiler das Flusen beim Kompilieren von Code ein. Diese Definition von Flusen stammt aus der Open-Source-Informationsseite für das Open-Source-JavaScript JavaScript ESLint, über das wir sprechen werden.
▍Warum brauche ich einen Linter für JavaScript?
Da 
JavaScript eine dynamische Programmiersprache mit schwacher Typisierung ist, ist der darin geschriebene Code anfällig für Fehler von Entwicklern. JavaScript ist eine interpretierte Sprache, daher werden Syntax und andere Fehler im Code normalerweise erst erkannt, nachdem dieser Code ausgeführt wurde.
Mit 
Lintern wie 
ESLint können Entwickler Probleme im Code finden, ohne ihn zu starten.
▍Warum ist ESLint ein Spezialwerkzeug?
Eine gute Frage wurde in den Titel dieses Abschnitts gestellt. Der Punkt hier ist, dass ESLint Plugins unterstützt. Codeüberprüfungsregeln sollten daher kein monolithisches Paket sein. Alles, was Sie brauchen, kann nach Bedarf angeschlossen werden. Jede dem System hinzugefügte Flusenregel ist autonom und kann unabhängig von den anderen ein- oder ausgeschaltet werden. Jeder Regel kann je nach Wunsch des Entwicklers eine Warnstufe zugewiesen werden - dies kann eine Warnung (Warnung) oder ein Fehler (Fehler) sein.
Wenn Sie ESLint verwenden, arbeiten Sie mit einem vollständig anpassbaren System, das Ihr Verständnis darüber widerspiegeln kann, wie der richtige Code aussehen sollte, und erfassen kann, welche Regeln Sie befolgen.
Unter den vorhandenen JavaScript-Stilrichtlinien sind die folgenden sehr beliebt:
Wie bereits erwähnt, verwende ich den Airbnb-Styleguide. Dieses Dokument hat mich von meinem Manager in dem Unternehmen beraten, in dem meine berufliche Laufbahn begann, und ich betrachte diesen Styleguide als mein wertvollstes Kapital.
Dieses Handbuch wird aktiv gepflegt - werfen Sie einen Blick auf das 
Repository auf GitHub. Hier werde ich eine Reihe von Regeln verwenden, die darauf basieren.
Lassen Sie uns nun an der Datei 
package.json und einige Abhängigkeiten hinzufügen:
 { "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" } } 
Bevor ich über die Arbeit mit dieser Konfiguration spreche, möchte ich auf die Projektabhängigkeiten 
package.json , die zu 
package.json hinzugefügt 
package.json . Ich glaube, bevor Sie einige Abhängigkeiten verwenden, sollten Sie wissen, welche Rolle sie spielen.
Daher werden wir die Rolle der hier vorgestellten Pakete diskutieren:
- babel-eslint- Ermöglicht die Verwendung von Flusen, um auf alles anzuwenden, was Babel gibt. Sie benötigen dieses Plugin nicht, wenn Sie keine Flow- oder experimentellen Funktionen verwenden, die ESLint noch nicht unterstützt.
- eslintist das Hauptwerkzeug zum- eslintCode.
- eslint-config-airbnb- Stellt Airbnb-Regeln als Konfiguration- eslint-config-airbnb, die geändert werden kann.
- eslint-plugin-babelist ein ESLint-Plugin, das das- babel-eslint. Es wurden die Regeln neu gestaltet, die bei Verwendung von- babel-eslintProbleme bei der Verarbeitung experimenteller Funktionen verursachen.
- eslint-plugin-import- Dieses Paket unterstützt die Verknüpfung neuer- import/export- eslint-plugin-importund hilft, Probleme zu vermeiden, die mit der falschen Schreibweise von Dateipfaden und Namen importierter Module verbunden sind.
- eslint-plugin-jsx-a11y- enthält Regeln zur Verfügbarkeit von JSX-Elementen für Menschen mit Behinderungen. Die Barrierefreiheit im Internet ist sehr wichtig.
- eslint-plugin-prettierprettier - Hilft ESLint und Prettier bei der Zusammenarbeit. Es sieht so aus: Wenn Prettier den Code formatiert, werden die ESLint-Regeln berücksichtigt.
- eslint-plugin-react- enthält ESLint-Regeln für React.
In diesem Artikel geht es nicht um 
package.json , aber in der obigen 
package.json gibt es Abhängigkeiten, die für 
package.json mit 
Jest / Enzyme entwickelt wurden . Wenn Sie sich nun dazu entschließen, diese Tools zum Testen zu verwenden, eine Beschreibung der relevanten Pakete.
- eslint-config-jest-enzyme- Dieses Paket wurde für Fälle entwickelt, in denen Sie- jest-environment-enzyme, was dazu führt, dass die Variablen React und Enzyme global sind. Dank dessen gibt ESLint keine Warnungen über solche Variablen aus.
- eslint-plugin-jest —ESlint-Plugin für Jest.
Die Datei enthält noch einige weitere Pakete, die wir später erläutern und die Automatisierungsprobleme behandeln. Dies ist 
husky und 
lint-staged .
Nachdem wir unsere Tools allgemein besprochen haben, werden wir weiterarbeiten.
Erstellen Sie die Datei 
.eslintrc.js im 
app Ordner:
 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'],   }, }; 
.eslintignore nun die 
.eslintignore Datei zum 
app Ordner hinzu:
 /.git /.vscode node_modules 
Lassen Sie uns nun darüber sprechen, wie die Datei 
.eslintrc.js ist und welche Bedeutung die darin dargestellten Konstruktionen haben.
Diese Datei hat folgende Struktur:
 module.exports = {  env:{},  extends: {},  plugin: {},  parser: {},  parserOptions: {},  rules: {}, }; 
Betrachten Sie die Blöcke dieser Datei, die durch Objekte mit den entsprechenden Namen dargestellt werden:
- env- Mit dieser- envkönnen Sie eine Liste von Umgebungen angeben, für die Sie den Code überprüfen möchten. In unserem Fall- nodeEigenschaften- es6,- browserund- nodeauf- true. Der Parameter- es6enthält ES6-Funktionen mit Ausnahme von Modulen (diese Funktion setzt im Parameter- ecmaVersionParameter- ecmaVersionautomatisch auf- 6). Der- browserParameter- browserglobale Browservariablen wie- Windows. Der Parameter- nodefügt globale Node.js-Umgebungsvariablen und -bereiche hinzu, z. B.- global. Details zu den Umgebungen finden Sie hier .
- extends- ist ein Array von Zeilen mit Konfigurationen, wobei jede zusätzliche Konfiguration die vorherige erweitert. Hier werden Airbnb-- airbnbverwendet, die zu- jestund dann zu- jest-enzymeerweitert werden.
- plugins- hier sind die Flusenregeln, die wir verwenden möchten. Wir wenden die Regeln- babel,- import,- jsx-a11y,- react,- prettier, über die wir bereits gesprochen haben.
- parser- ESLint verwendet standardmäßig den Espree-- parserDa wir jedoch mit Babel arbeiten, müssen wir Babel-ESLint verwenden .
- parserOptions- Da wir den Standardparser in- babel-eslint, müssen wir auch die Eigenschaften in diesem Block festlegen. Die auf- 6- ecmaVersionEigenschaft- ecmaVersionzeigt ESLint an, dass der ES6-Code überprüft wird. Da wir Code in- EcmaScriptModulen schreiben, wird die Eigenschaft- sourceTypeauf- module. Und schließlich wird, da wir React verwenden,- jsxJSX verwenden, ein Objekt mit dem auf- jsxgesetzten- jsxSchlüssel in die Eigenschaft- ecmaFeatures.
- rules- Ich mag diesen Teil der- .eslintrc.jsDatei am meisten, da Sie damit ESLint-Regeln konfigurieren können. Alle Regeln, die wir mithilfe von Plugins erweitert oder hinzugefügt haben, können geändert oder neu definiert werden. Dies erfolgt im Regelblock. Der Text der Datei enthält Kommentare zu den Regeln.
Lassen Sie uns nun über die 
.eslintignore Datei sprechen. Diese Datei akzeptiert eine Liste von Pfaden, die Ordner darstellen, deren Inhalt nicht mit ESLint verarbeitet werden soll.
Hier werden drei Ordner definiert:
- /.git- Ich benötige ESLint nicht, um Dateien zu überprüfen, die sich auf Git beziehen.
- /.vscode- Das Projekt hat diesen Ordner, da ich VS-Code verwende. Hier speichert der Editor Konfigurationsinformationen, die für jedes Projekt festgelegt werden können. Diese Daten sollten auch nicht vom Linter verarbeitet werden.
- node-modules- Abhängigkeitsdateien müssen auch nicht mit einem Linter überprüft werden.
Schauen wir uns nun einige neue Skripte an, die in 
package.json erschienen 
package.json . Hier sind sie:
 "lint": "eslint --debug src/" "lint:write": "eslint --debug src/ --fix" 
Wenn Sie die erste davon mit dem Befehl 
yarn lint oder 
npm run lint der Linter alle Dateien im Verzeichnis 
src und zeigt einen detaillierten Bericht über die Dateien an, in denen Fehler gefunden wurden. Mit diesem Bericht können Sie diese Fehler korrigieren.
Fusselskript ausführenWenn Sie das zweite Skript ausführen (Garnfussel 
yarn lint:write ), führt ESLint dieselbe Überprüfung durch, die zuvor durchgeführt wurde. Der einzige Unterschied besteht darin, dass das System in diesem Modus versucht, die erkannten Fehler zu beheben und den Code in die bestmögliche Form zu bringen.
ESLint-Erweiterung für VS-Code
Wir haben bereits Prettier und ESLint konfiguriert, aber um die Funktionen dieser Tools nutzen zu können, müssen wir Skripte ausführen. Dies ist nicht sehr praktisch, versuchen Sie es also zu beheben. Wir möchten nämlich sicherstellen, dass das Formatieren und Flusen des Codes durch den Befehl zum Speichern der Datei im Editor ausgeführt wird. Darüber hinaus möchten wir den Code vor dem Festschreiben fusseln und formatieren.
Wir verwenden als Beispiel den VS-Code-Editor. Wir benötigen 
die ESLint-Erweiterung für VS Code. Um es zu installieren, können Sie das VS Code-Erweiterungsfenster öffnen ( 
ctrl+shift+x ). 
eslint hier im Suchfeld 
eslint . Eine Liste der Erweiterungen wird angezeigt. Was uns interessiert, ist derjenige, dessen Entwicklerinformationen Dirk Baeumer sind. Starten Sie nach der Installation dieser Erweiterung den Editor neu.
Erstellen 
.vscode nun im Stammordner des Projekts ( 
app ) den Ordner 
.vscode (achten Sie auf den Punkt am Anfang des Namens - dies ist wichtig). Erstellen Sie in diesem Ordner eine Datei 
settings.json mit den folgenden Inhalten:
 { "editor.formatOnSave": false, "eslint.autoFixOnSave": true, } 
Betrachten Sie den Inhalt.
- Die auf falseeditor.formatOnSaveEigenschafteditor.formatOnSavegibt an, dass für die Dateiformatierung keine Standardkonfiguration erforderlich ist, da dies zu einem Konflikt mit ESLint und Prettier führen kann.
- Die Eigenschaft eslint.autoFixOnSaveauftrue, da das installierte Plug-in jedes Maleslint.autoFixOnSavemuss, wenn eine Datei gespeichert wird. Da ESLint und Prettier in einem Projekt zusammenarbeiten, führt das Speichern der Datei sowohl zu Formatierung als auch zu Code-Flusen.
Es ist wichtig zu beachten, dass jetzt, wenn das Skript 
lint:write ausgeführt wird, sowohl Flusen als auch Code formatiert werden.
Stellen Sie sich Ihre Gefühle vor, wenn Sie einen Projektcode von 20.000 Zeilen erhalten, den Sie überprüfen und verbessern müssten. Stellen Sie sich nun vor, Sie müssten dies manuell tun. Eine solche Arbeit würde wahrscheinlich einen Monat dauern. Mit Hilfe der oben genannten Automatisierungstools ist dies alles in etwa 30 Sekunden erledigt.
Nachdem Sie nun alles eingerichtet haben, was Sie benötigen, kümmert sich der Editor jedes Mal, wenn Sie die Datei mit dem Code speichern, um die Überprüfung und Formatierung des Programmtextes. Hier geht es jedoch um den VS-Code-Editor. Es ist möglich, dass jemand in Ihrem Team einen anderen Editor bevorzugt. Daran ist nichts auszusetzen, aber damit jeder bequem arbeiten kann, müssen wir etwas anderes ausarbeiten, um es zu automatisieren.
Husky
Mit dem Husky-Paket können Sie Git-Hooks verwenden. Dies bedeutet, dass Sie die Möglichkeit haben, bestimmte Aktionen auszuführen, bevor Sie den Repository-Code festschreiben oder senden.
Um die Funktionen von Husky nutzen zu können, installieren Sie zunächst dieses Paket:
 yarn add  
package.json Folgendes zu 
package.json :
 "husky": {     "hooks": {         "pre-commit": "YOUR_COMMAND_HERE",    "pre-push": "YOUR_COMMAND_HERE"    } }, 
Dies führt dazu, dass vor dem Ausführen des 
commit oder 
push Befehls ein bestimmtes Skript aufgerufen wird, das beispielsweise Codetests oder Formatierungen durchführt.
Details zu Husky finden Sie 
hier .
Fussel inszeniert
Mit dem 
Lint-Staged- Paket können Sie indizierte Dateien mit dem Linter überprüfen, um zu verhindern, dass Fehler an das Repository gesendet werden.
Flusen ist sinnvoll, bevor Code festgeschrieben wird. Auf diese Weise können Sie sicherstellen, dass Fehler nicht in das Repository eindringen, und den dort ankommenden Code einheitlich gestalten. Das Flusen zur Überprüfung des gesamten Projekts kann jedoch eine zu lange Aufgabe sein, und die Ergebnisse einer solchen Überprüfung können bedeutungslos sein. Letztendlich muss beim Flusen möglicherweise Dateien verfügbar gemacht werden, die Sie festschreiben möchten.
Mit Lint-Staged können Sie eine Reihe beliebiger Aufgaben für indizierte Dateien ausführen, die nach einem Suchmuster gefiltert werden. Details dazu finden Sie 
hier .
Installieren Sie das Lint-Paket:
 yarn add  
package.json dann in der Datei 
package.json Folgendes hinzu:
 "lint-staged": {     "*.(js|jsx)": ["npm run lint:write", "git add"] }, 
Dank dieser Konstruktion wird zuerst der Befehl 
lint:write ausgeführt, der den Inhalt der Datei überprüft und Fehler behebt. Anschließend werden die Dateien mit dem Befehl 
git add zum Index hinzugefügt. Dieser Befehl richtet sich 
.js an 
.js und 
.jsx Dateien, aber das Gleiche kann mit Dateien anderer Typen durchgeführt werden.
Husky- und Lint-inszeniertes Teilen
Stellen Sie sich ein Aktionsdiagramm vor, mit dem Sie den nächsten Workflow organisieren können. Jedes Mal, wenn Sie Dateien mit Code festschreiben, führt das System vor dem Ausführen dieses Vorgangs das 
lint-staged Skript aus, das wiederum das 
lint:write ausführt, das das Flusen und Formatieren des Codes ausführt. Danach werden die Dateien zum Index hinzugefügt und anschließend festgeschrieben. Es scheint mir, dass es sehr bequem ist. Tatsächlich ist dies im zuvor präsentierten Code der Datei 
package.json bereits implementiert. Wir haben zuvor nur nicht darüber gesprochen.
Hier ist noch einmal der Inhalt unserer 
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" } } 
Nachdem Sie nun wissen, wie Husky und Lint inszeniert werden, können Sie deren Auswirkungen auf die Arbeit mit Git bewerten. Angenommen, die folgenden Befehle wurden ausgeführt:
 $ git add . $ git commit -m "some descriptive message here" 
Es ist klar, dass der Code vor dem 
.eslintrc.js auf Übereinstimmung mit den in 
.eslintrc.js angegebenen Regeln 
.eslintrc.js und gegebenenfalls behoben wird. Dank dessen gelangen Fehler niemals in das Repository eines Arbeitsprojekts.
Jetzt wissen Sie, wie Sie Prettier, ESLint, Husky und Lint-inszeniert in Ihr Projekt integrieren können.
Ich möchte Sie daran erinnern, dass wir oben gesagt haben, dass nicht alle Mitglieder Ihres Teams meinen bevorzugten VS-Code verwenden. Damit sie alle bequem funktionieren, müssen wir uns mit der 
.editorconfig Datei befassen.
.Editorconfig-Datei
Verschiedene Mitglieder Ihres Teams verwenden möglicherweise unterschiedliche Editoren. Sie werden gezwungen, einen beliebigen Editor für irgendetwas zu verwenden. Damit jedoch alle dieselben Einstellungen verwenden können, z. B. Einrückungen oder Zeilenvorschübe, verwenden wir die Datei. 
editorconfig . .
, . , , WebStorm, AppCode, Atom, Eclipse, Emacs, BBEdit .
app .editorconfig :
 # 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 
, :
- trim_trailing_whitespace = false—- .md- .- .js-- false.
- indent_style = space— .
- indent_size = 2— .
- end_of_line = lf—- lf. , , . .
- insert_final_newline = true— .
- max_line_length = 100— 100 .
Zusammenfassung
, , , . , , .
Liebe Leser! ? ?