Prettier, ESLint, Husky, Lint-Staged und EditorConfig: Tools zum Schreiben von aufgeräumtem Code

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 --dev prettier 

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:

  1. Formatieren Sie diesen Code manuell.
  2. Verwenden Sie ein automatisiertes Tool.
  3. 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: true und 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: 2 die 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 Prettier

In 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.
  • eslint ist das Hauptwerkzeug zum eslint Code.
  • eslint-config-airbnb - Stellt Airbnb-Regeln als Konfiguration eslint-config-airbnb , die geändert werden kann.
  • eslint-plugin-babel ist ein ESLint-Plugin, das das babel-eslint . Es wurden die Regeln neu gestaltet, die bei Verwendung von babel-eslint Probleme bei der Verarbeitung experimenteller Funktionen verursachen.
  • eslint-plugin-import - Dieses Paket unterstützt die Verknüpfung neuer import/export eslint-plugin-import und 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-prettier prettier - 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 env können Sie eine Liste von Umgebungen angeben, für die Sie den Code überprüfen möchten. In unserem Fall node Eigenschaften es6 , browser und node auf true . Der Parameter es6 enthält ES6-Funktionen mit Ausnahme von Modulen (diese Funktion setzt im Parameter ecmaVersion Parameter ecmaVersion automatisch auf 6 ). Der browser Parameter browser globale Browservariablen wie Windows . Der Parameter node fü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- airbnb verwendet, die zu jest und dann zu jest-enzyme erweitert 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- parser Da 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 ecmaVersion Eigenschaft ecmaVersion zeigt ESLint an, dass der ES6-Code überprüft wird. Da wir Code in EcmaScript Modulen schreiben, wird die Eigenschaft sourceType auf module . Und schließlich wird, da wir React verwenden, jsx JSX verwenden, ein Objekt mit dem auf jsx gesetzten jsx Schlüssel in die Eigenschaft ecmaFeatures .
  • rules - Ich mag diesen Teil der .eslintrc.js Datei 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ühren

Wenn 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 false editor.formatOnSave Eigenschaft editor.formatOnSave gibt 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.autoFixOnSave auf true , da das installierte Plug-in jedes Mal eslint.autoFixOnSave muss, 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 --dev husky 

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 --dev lint-staged 

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 = lflf . , , . .
  • insert_final_newline = true — .
  • max_line_length = 100 — 100 .

Zusammenfassung


, , , . , , .

Liebe Leser! ? ?

Source: https://habr.com/ru/post/de428173/


All Articles