Qualität geht vor! 5 einfache Schritte zum Linting Ihres Codes mit GitHub-Workflows im JavaScript-Projekt

Was sollen wir tun, wenn die Projekt gering ist oder der Kunde noch nicht weiß, ob es sich lohnt, mehr zu investieren? Offensichtlich ist bei der MVP-Phase des Projekts, Code Styling oder Unit-Tests haben nicht die höchste Priorität. Investoren wollen in der Regel eine gute Produkt Und mal ehrlich - wenn es funktioniert, muss es doch nicht getestet werden, oder?

Ich habe einige Erfahrung mit Erstellung von Anwendungen von Grund aufauch ohne die Anwendung von Best Practices in erster Linie. Einige geschäftliche Umstände zwangen mich dazu, nach einem Kompromiss zwischen den Budgetplänen eines Investors und der "Nice-to-have"-Liste des Entwicklers zu suchen. Wenn Sie GitHub verwenden, lassen sich die meisten der üblichen Probleme im Zusammenhang mit der Codequalität glücklicherweise in wenigen Minuten lösen.

In diesem Artikel zeige ich Ihnen, wie Sie GitHub-Workflows in der Node.js-Umgebung verwenden können, um Ihre Codebase zu standardisieren.

Ein paar Annahmen, bevor wir beginnen:

• Sie sind mit NPM und der Linux-Konsole vertraut.
• Sie haben einige Erfahrung mit Style-Präprozessoren, Modulladern, Bundlern usw.
• Sie wissen, wozu Linters da sind, und wollen sie wirklich für Ihre Projekte verwenden.

1. Typische JavaScript-Projektstruktur

If you ever used some JS frameworks like Vue or React, you can easily spot some common things between them, e.g.:

• /src Verzeichnis mit Ihrer gesamten JS-Logik und Komponenten,
• /test Verzeichnis für Unit- und e2e-Tests,
• /Vermögenswerte Verzeichnis für Stile, Bilder usw.

Auch wenn es sich um JavaScript Projekt, arbeiten wir in Knotenpunkt Umgebung, also sollte es offensichtlich auch einige Node-Sachen geben wie paket.json, paket-lock.json und /node_modules Katalog in unserem Stammverzeichnis.

All diese Dinge sind an ihrem Platz - das nennen wir die Tagung. Frameworks werden erfunden, um einige vernünftige Konventionen bereitzustellen, so dass wir uns normalerweise nicht einmal um das ursprüngliche Entwurfsmuster kümmern müssen. Da ich in diesem Beispiel einige Ansätze erläutern möchte, werde ich keine gebrauchsfertigen Lösungen wie Vue CLI verwenden.

Es ist an der Zeit zu verstehen, was sich hinter all diesen magischen Fusselskripten verbirgt!

2. Erweiterung des typischen Node-Projekts

Um qualitativ hochwertige Lösungen anbieten zu können, sind Linters das erste, womit wir beim Einrichten eines neuen Projekts beginnen sollten. Konzentrieren wir uns auf zwei Linters - Stylelint für Stile (*.scss) und ESLint für Quelldateien (*.js). Beide Linters sind bei NPM verfügbar und ziemlich einfach zu konfigurieren. Die Verwendung von Linters erfordert den Installationsprozess, das Hinzufügen von Konfigurationsdateien und die Definition von Projektskripten. Lassen Sie uns Schritt für Schritt vorgehen.

3. Hinzufügen von Stylelint

Die Installation von Stylelint in der Node-Umgebung ist sehr einfach. Gemäß offizielle Dokumentemüssen Sie nur noch laufen:

npm install --save-dev stylelint stylelint-konfig-standard

und warten, bis es fertig ist.

stylelint-konfig-standard bietet einen Standardsatz von Linting-Regeln und kann durch ein beliebiges Paket ersetzt werden, das Ihren Bedürfnissen besser entspricht (z. B. Airbnb-Stil). Erstellen Sie dann eine neue versteckte Datei .stylelintrc.jsondie Stylelint-Konfigurationsdatei, die für das Laden unserer vordefinierten Regeln verantwortlich ist:

{
    "extends": "stylelint-config-standard"
}

Im Moment fehlt nur noch ein NPM-Skript (oder Skripte), das in der package.json-Datei deklariert ist, um das Linting unserer SCSS-Dateien zu starten. Hier ist mein Vorschlag:

"Skripte": {
    "lint:scss": "stylelint '**/*.scss' --syntax scss -f verbose --color",
    "lint:scss:fix": "stylelint '**/*.scss' --syntax scss --fix -f verbose -color"
}

Wie Sie sehen können, habe ich das Skript mit -fix zu verwenden, bevor die Änderungen in das Repository übertragen werden.

Denken Sie daran - es ist eine schlechte Praxis, die -fix in Ihrem CI-Flow, denn dann wird der Code, den Sie an die Produktion übergeben, im Repository nicht richtig gestylt. Deshalb brauchen wir die beiden Skripte.

Testen wir unseren Linter, indem wir eine Datei erstellen /assets/scss/styles.scss mit einigen Inhalten, wie:

body {
                    Hintergrundfarbe: #fff;
}

npm lint:scss ausführen

In Ihrer Konsole sollten Sie etwa Folgendes sehen:

> stylelint '**/*.scss' --syntax scss -f verbose --color

assets/scss/styles.scss

2:21 ✖ Erwartete Einrückung von 2 Leerzeichen Einrückung

1 Quelle geprüft

~/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

1 Problem gefunden

Schweregrad "Fehler": 1

Einrückung: 1

npm ERR! code ELIFECYCLE

npm ERR! errno 2

npm ERR! [email protected] lint:scss: `stylelint '**/*.scss' --syntax scss -f verbose --color`

npm ERR! Exit-Status 2

Das bedeutet, dass unser Linter tatsächlich funktioniert!

Die Ausgabe zeigt genau an, welche Zeile einen Fehler verursacht und beschreibt das zu lösende Problem. Einige Probleme können nicht automatisch behoben werden, da sie die Entscheidung eines Entwicklers erfordern, aber in den meisten Fällen müssen Sie nur denselben Befehl mit -fix Option, also führen wir sie aus.

npm lint:scss:fix ausführen

Jetzt sollten Sie eine grüne Ausgabe sehen, bei der keine Fehler gefunden wurden:

stylelint '**/*.scss' --syntax scss --fix -f verbose --color


1 Quelle geprüft

/Benutzer/wojciechbak/Codest/Projekte/github-workflow-demo/assets/scss/styles.scss

0 Probleme gefunden

4. Hinzufügen von ESLint

Dieser Schritt ist fast derselbe wie der vorherige. Wir werden ESLint installieren, einige Standardregeln definieren und zwei aufrufbare NPM-Skripte deklarieren - eines für CI, eines für Pre-Push. Gehen wir das durch!

Wenn Sie NPM bei Ihrer täglichen Arbeit verwenden, möchten Sie vielleicht ESLint global installieren. Wenn nicht, lesen Sie bitte die Installationsanweisungen in offizielle Dokumente.

npm install -g eslint

Wenn der Befehl eslint auf Ihrem Rechner verfügbar ist, führen Sie ihn einfach in Ihrem Projekt aus:

eslint --init

Befolgen Sie die weiteren Anweisungen in Ihrem Terminal und treffen Sie einige Projektentscheidungen, z. B:

• Javascript oder TypeScript
• Airbnb-Stil oder Google-Stil
• Konfigurationstyp (JSON-Datei, JS-Datei oder Inline in paket.json)
• ES-Module (Import/Export) oder erfordern Syntax

An dieser Stelle lohnt es sich, ein Wort über den Code-Formatierer namens Prettier zu schreiben. Es ist vollständig standardisiert und kompatibel mit den meisten Code-Editoren (z.B. VS Code). Prettier bietet viele vordefinierte Regeln für die Gestaltung von Code, arbeitet mit Linters zusammen und kann eine große Unterstützung bei der Suche nach Top-Qualität des Codes sein. Um zu verstehen, was Prettier genau ist, besuchen Sie diese Seite Vergleich aus den offiziellen Dokumenten.

Wenn dies geschehen ist, wird die ESlint-Konfigurationsdatei (z.B. .eslintrc.json(je nachdem, was Sie vorher gewählt haben) sollte in Ihrem Stammverzeichnis erscheinen, irgendwo neben .stylelintrc.json vorher erstellt.

Jetzt müssen wir Skripte definieren in paket.json Datei, genau wie bei SCSS-Dateien:

"Skripte": {
    "lint:js": "eslint '**/*.js' --ignore-pattern node_modules/",
    "lint:js:fix": "eslint '**/*.js' --ignore-pattern node_modules/ --fix"
}

Herzlichen Glückwunsch! ESLint ist jetzt sofort einsatzbereit. Lassen Sie uns überprüfen, ob es korrekt funktioniert. erstellen /src/index.js Datei mit einigem Inhalt:

console.log("etwas");

Linter ausführen:

npm lint:js ausführen


Die Ausgabe sollte wie folgt aussehen:

> eslint '**/*.js' --ignore-pattern node_modules/

~/Codest/Projects/github-workflow-demo/src/index.js

1:1 warning Unerwartete Konsolenanweisung no-console

✖ 1 Problem (0 Fehler, 1 Warnung)

Diese Warnung wird nicht verschwinden, wenn Sie -fix Option, denn linters hat keinen Einfluss auf potenziell sinnvollen Code. Sie sind nur für das Styling von Codeeinschließlich Leerzeichen, Zeilenumbrüche, Semikolons, Anführungszeichen usw.

5. Definition von GitHub-Workflows

GitHub-Workflows sind eine ziemlich gut dokumentierte Sache. Fühlen Sie sich frei, tiefer in diese zu graben, aber für jetzt, ich werde einen einfachen Workflow implementieren, um unseren Code nach dem Push auf das Remote-Repository (natürlich auf GitHub gehostet) zu lint.

erstellen. /.github/workflows Verzeichnis und neue code-qualität-workflow.yml Datei enthalten, da GitHub-Workflows mit YAML-Dateien definiert werden müssen.

Um einen ordnungsgemäßen Arbeitsablauf durchzuführen, müssen wir einige Fragen beantworten:

• Wann wollen wir unseren Workflow ausführen (bei Push, bei Pull Request, bei Merge usw.)?
• Sollen bestimmte Situationen ausgeschlossen werden (z. B. Push-to-Branch-Master)?
• Welche Umgebung müssen wir einrichten, um unsere Befehle korrekt auszuführen (in diesem Beispiel - Node)?
• Müssen wir Abhängigkeiten installieren? Wenn ja, wie sollten wir sie zwischenspeichern?
• Welche Schritte müssen wir unternehmen, um die Prüfung abzuschließen?

Nach einigen Überlegungen und einigen Stunden Arbeit mit docs example .yml Datei kann folgendermaßen aussehen:

Name: Codequalität

Ein: 'Push'

Aufträge:
  Code-Qualität:
    name: Lint Quellcode
    läuft auf: ubuntu-latest
    Schritte:
    - verwendet: actions/checkout@v1

    - Name: Knoten einrichten
      verwendet: actions/setup-node@v1
      mit:
        node-version: '12.1'

    - name: Cache-Abhängigkeiten
      verwendet: actions/cache@v1
      mit:
        Pfad: ./node_modules
        Schlüssel: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        Wiederherstellungs-Schlüssel: |
          $(( runner.OS ))-Abhängigkeiten-$(( env.cache-name ))-
          $(( runner.OS ))-Abhängigkeiten-
          $(( runner.OS ))-

    - name: Abhängigkeiten installieren
      ausführen: |
        npm installieren

    - Name: Lint-Dateien
      ausführen: |
        npm lint ausführen

GitHub stellt alle benötigten Umgebungsdaten zur Verfügung. In der letzten Zeile führen wir den Befehl npm lint ausführen die vorher nicht definiert war:

"Skripte": {
    "lint": "npm run lint:js && npm run lint:scss"
}

Beachten Sie, dass ich in unserem Arbeitsablauf nicht mit :fix Befehle.

Wenn alle diese Schritte erledigt sind, können Sie diese schöne Ausgabe von GitHub genießen, bevor Sie Ihren Pull Request zusammenführen: