Kwaliteit eerst! 5 eenvoudige stappen om je code te linten met GitHub workflows in JavaScript project

Wat moeten we doen als de project klein is of de klant nog steeds niet weet of het de moeite waard is om meer te investeren? Het is duidelijk dat MVP-fase van het project, code styling of unit tests zijn niet de hoogste prioriteit. Investeerders willen meestal een goede product en kom op - als het werkt, hoeft het niet getest te worden, toch?

Eigenlijk heb ik enige ervaring in apps vanaf nul bouwenZelfs zonder best practices te gebruiken. Sommige zakelijke omstandigheden dwongen me te zoeken naar het compromis tussen de budgetplannen van een investeerder en de "nice-to-have" lijst van de ontwikkelaar. Gelukkig kunnen, als je GitHub gebruikt, de meeste veelvoorkomende problemen met betrekking tot de kwaliteit van code in een paar minuten opgelost worden.

In dit artikel laat ik je zien hoe je GitHub workflows kunt gebruiken in de Node.js omgeving om je codebase te standaardiseren.

Een paar aannames voordat we beginnen:

• Je bent bekend met NPM en Linux console.
• Je hebt enige ervaring met style preprocessors, module loaders, bundlers, enz.
• Je weet waar linters voor zijn en je wilt ze echt gebruiken in je projecten.

1. Typische JavaScript projectstructuur

Als je ooit JS frameworks hebt gebruikt zoals Vue of React, kun je gemakkelijk zien welke dingen ze gemeen hebben, bijv:

• /bron map met al je JS-logica en componenten,
• /test map voor unit- en e2e-tests,
• /activa map voor stijlen, afbeeldingen, enz.

Zelfs als we het hebben over JavaScript project werken we in Knooppunt omgeving, dus er moet natuurlijk ook wat Node spul zijn zoals pakket.json, pakket-slot.json en /node_modules catalogus in onze hoofdmap.

Al deze dingen zijn op hun plaats - dat noemen we de conventie. Frameworks zijn uitgevonden om een aantal redelijke conventies te bieden, dus meestal hoeven we ons niet eens druk te maken over het initiële ontwerppatroon. In dit voorbeeld wil ik enkele benaderingen uitleggen, ik zal geen kant-en-klare oplossingen toepassen zoals Vue CLI.

Tijd om te begrijpen wat er onder al deze magische scripts schuilgaat!

2. Het typische Node-project uitbreiden

Om oplossingen van hoge kwaliteit te bieden, zijn linters het eerste waar we mee moeten beginnen tijdens het opzetten van een nieuw project. Laten we ons richten op twee linters - Stylelint voor stijlen (*.scss) en ESLint voor bronbestanden (*.js). Beide linters zijn beschikbaar op NPM en vrij eenvoudig te configureren. Het gebruik van linters vereist het doorlopen van het installatieproces, het toevoegen van configuratiebestanden en het definiëren van projectscripts. Laten we het stap voor stap doen.

3. Stylelint toevoegen

De installatie van Stylelint in de Node-omgeving is heel eenvoudig. Volgens officiële documentenJe hoeft alleen maar te rennen:

npm install --save-dev stylelint stylelint-config-standaard

en wacht tot het klaar is.

stylelint-config-standaard biedt een standaardset van lintingregels en kan worden vervangen door een pakket dat beter past bij je behoeften (bijv. Airbnb stijl). Maak vervolgens een nieuw verborgen bestand .stylelintrc.jsonDit is het Stylelint configuratiebestand, dat verantwoordelijk is voor het laden van onze vooraf gedefinieerde regels:

{
    "extends": "stylelint-config-standaard".
}

Op dit moment ontbreekt er alleen nog een NPM-script (of scripts) in package.json om onze SCSS-bestanden te linten. Dit is mijn voorstel:

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

Zoals je kunt zien, heb ik het script gedeclareerd met daarin -fix optie - deze moet je gebruiken voordat je wijzigingen naar het archief pushed.

Onthoud - het is een slechte gewoonte om -fix in je CI flow, want dan wordt de code die je doorgeeft aan productie niet correct opgemaakt in de repository. Daarom hebben we beide scripts nodig.

Laten we onze linter testen door een bestand te maken /assets/scss/styles.scss met wat inhoud, zoals:

lichaam {
                    achtergrondkleur: #fff;
}

npm uitvoeren lint:scss

Je zou in je console iets als dit moeten zien:

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

activa/scss/styles.scss

2:21 ✖ Verwachte inspringing van 2 spaties inspringing

1 bron gecontroleerd

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

1 probleem gevonden

ernstgraad "fout": 1

inspringen: 1

npm fout! code ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Afsluitstatus 2

Dit betekent eigenlijk dat onze linter werkt!

De uitvoer laat precies zien welke regel een fout veroorzaakt en beschrijft het probleem dat opgelost moet worden. Sommige problemen kunnen niet automatisch opgelost worden omdat er een beslissing van de ontwikkelaar voor nodig is, maar in de meeste gevallen hoeft alleen maar hetzelfde commando uitgevoerd te worden met -fix optie, dus laten we die uitvoeren.

npm run lint:scss:fix

Nu zou je groene uitvoer moeten zien zonder fouten:

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


1 bron gecontroleerd

/Users/wojciechbak/Codest/Projecten/github-workflow-demo/assets/scss/styles.scss

0 problemen gevonden

4. ESLint toevoegen

Deze stap is bijna hetzelfde als de vorige. We gaan ESLint installeren, een aantal standaard regels definiëren en twee oproepbare NPM scripts declareren - één voor CI, één voor pre-push. Laten we hier doorheen gaan!

Als je NPM gebruikt in je dagelijkse werk, wil je misschien ESLint wereldwijd installeren. Als je dat niet doet, bekijk dan de installatie-instructies in officiële documenten.

npm installeren -g eslint

Als het eslint commando beschikbaar is op je machine, voer dit dan gewoon uit in je project:

eslint --initialiseren

Volg de verdere instructies in je terminal en neem een paar projectbeslissingen zoals:

• Javascript of TypeScript
• Airbnb-stijl of Google-stijl
• configuratietype (JSON-bestand, JS-bestand of inline in pakket.json)
• ES-modules (import/export) of nodig hebben syntax

Op deze plaats is het de moeite waard om iets te schrijven over code formatter genaamd Prettier. Het is volledig gestandaardiseerd en compatibel met de meeste code editors (bijv. VS Code). Prettier biedt vele sets van voorgedefinieerde code styling regels, werkt samen met linters en kan een geweldige ondersteuning zijn in het najagen van topkwaliteit van de code. Om te begrijpen wat Prettier precies is, bezoek deze vergelijking uit officiële documenten.

Als het gedaan is, zal het ESlint configuratiebestand (bijv. .eslintrc.jsonafhankelijk van wat je eerder hebt gekozen) zou in je hoofddirectory moeten verschijnen, ergens naast .stylelintrc.json eerder gemaakt.

Nu moeten we scripts definiëren in pakket.json bestand, hetzelfde als voor SCSS-bestanden:

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

Gefeliciteerd! ESLint is nu klaar voor gebruik. Laten we eens kijken of het goed werkt. Maak /src/index.js bestand met wat inhoud:

console.log("iets");

Linter uitvoeren:

npm uitvoeren lint:js


De uitvoer zou er als volgt uit moeten zien:

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

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

1:1 waarschuwing Onverwachte console-instructie no-console

✖ 1 probleem (0 fouten, 1 waarschuwing)

Deze waarschuwing verdwijnt niet na het gebruik van -fix optie, omdat linters hebben geen invloed op potentieel zinvolle code. Ze zijn alleen voor code stylinginclusief witregels, newlines, puntkomma's, aanhalingstekens enz.

5. GitHub workflows definiëren

GitHub workflows zijn behoorlijk goed gedocumenteerd. Voel je vrij om hier dieper in te duiken, maar voor nu ga ik een eenvoudige workflow implementeren om onze code te linten na het pushen naar de remote repository (uiteraard gehost op GitHub).

Maak /.github/workflows map en nieuwe code-kwaliteit-workflow.yml bestand daarin, omdat GitHub workflows gedefinieerd moeten worden met YAML bestanden.

Om een goede workflow uit te voeren, moeten we een aantal vragen beantwoorden:

• Wanneer willen we onze workflow uitvoeren (op push, op pull request, op samenvoegen etc.)?
• Willen we sommige situaties uitsluiten (zoals push naar branch master)?
• Welke omgeving moeten we instellen om onze commando's correct uit te voeren (in dit voorbeeld - Node)?
• Moeten we afhankelijkheden installeren? Zo ja, hoe moeten we de cache plaatsen?
• Welke stappen moeten we nemen om de controle te voltooien?

Na wat overwegingen en een paar uur werk met docs voorbeeld .yml bestand kan er als volgt uitzien:

naam: Code kwaliteit

aan: "push

banen:
  code-kwaliteit:
    naam: Lint broncode
    draait op: ubuntu-latest
    stappen:
    - gebruikt: actions/checkout@v1

    - naam: Node instellen
      gebruikt: actions/setup-node@v1
      met:
        node-versie: '12.1'

    - naam: Cache-afhankelijkheden
      gebruikt: actions/cache@v1
      met:
        pad: ./node_modules
        sleutel: $(( runner.OS ))-afhankelijkheden-$(( hashFiles('**/package-lock.json') ))
        herstel-sleutels: |
          $(( runner.OS ))-afhankelijkheden-$(( env.cache-naam ))-
          $(( runner.OS ))-afhankelijkheden-
          $(( runner.OS ))-afhankelijkheden

    - naam: afhankelijkheden installeren
      uitvoeren: |
        npm installeren

    - naam: Lint bestanden
      uitvoeren: |
        npm run lint

GitHub biedt alle omgevingsdingen die we nodig hebben. In de laatste regel voeren we het commando npm lint uitvoeren die eerder niet gedefinieerd was:

"scripts": {
    "lint": "npm run lint:js && npm run lint:scss".
}

Merk op dat ik in onze workflow geen gebruik maak van :fix commando's.

Als al deze stappen gedaan zijn, kun je genieten van deze prachtige uitvoer van GitHub voordat je je Pull Request samenvoegt: