Kvalitet først! 5 nemme trin til at lint'e din kode med GitHub-workflows i JavaScript-projektet

Hvad skal vi gøre, når projekt er lille, eller at kunden stadig ikke ved, om det er værd at investere mere? Det er klart, at på MVP-fasen af projektet, Kode styling eller unit tests er ikke den højeste prioritet. Investorer vil normalt gerne have en god produkt Og kom nu - hvis det virker, behøver det ikke at blive testet, vel?

Jeg har faktisk en del erfaring med bygge apps fra bundenselv uden at bruge bedste praksis i første omgang. Nogle forretningsmæssige omstændigheder tvang mig til at lede efter et kompromis mellem en investors budgetplaner og udviklerens "nice-to-have"-liste. Hvis du bruger GitHub, kan de fleste af de almindelige problemer med kodekvalitet heldigvis løses på få minutter.

I denne artikel vil jeg vise dig, hvordan du bruger GitHub-workflows i Node.js-miljøet til at standardisere din kodebase.

Et par antagelser, før vi begynder:

• Du er fortrolig med NPM og Linux-konsollen.
• Du har en vis erfaring med stilpræprocessorer, modulindlæsere, bundlere osv.
• Du ved, hvad linters er til for, og du vil virkelig gerne bruge dem i dine projekter.

1. Typisk JavaScript-projektstruktur

Hvis du nogensinde har brugt nogle JS-frameworks som Vue eller React, kan du nemt få øje på nogle fælles ting mellem dem, f.eks:

• /src med al din JS-logik og alle dine komponenter,
• /test til unit- og e2e-tests,
• /aktiver til stilarter, billeder osv.

Selv hvis vi taler om JavaScript projekt, arbejder vi i Knudepunkt miljø, så der bør naturligvis også være nogle Node-ting som pakke.json, pakke-lås.json og /node_modules katalog i vores rodmappe.

Alle disse ting er på deres plads - det er det, vi kalder the Konvention. Frameworks er opfundet for at give nogle rimelige konventioner, så normalt behøver vi ikke engang at bekymre os om det oprindelige designmønster. I dette eksempel vil jeg forklare nogle tilgange, og jeg vil ikke anvende færdige løsninger som Vue CLI.

Det er tid til at forstå, hvad der gemmer sig bag alle disse magiske fnugscripts!

2. Udvidelse af det typiske Node-projekt

For at levere løsninger af høj kvalitet er linters det første, vi bør starte med, når vi opretter et nyt projekt. Lad os fokusere på to linters - Stylelint til stilarter (*.scss) og ESLint til kildefiler (*.js). Begge disse linters er tilgængelige på NPM og ret nemme at konfigurere. Brug af linters kræver, at man gennemgår installationsprocessen, tilføjer konfigurationsfiler og definerer projektscripts. Lad os gøre det trin for trin.

3. Tilføjelse af Stylelint

Installationen af Stylelint i Node-miljøet er virkelig enkel. I henhold til officielle dokumenterskal du bare løbe:

npm install --save-dev stylelint stylelint-config-standard

og vent, til den er færdig.

stylelint-config-standard giver et standardsæt af linting-regler og kan erstattes med enhver pakke, der passer bedre til dine behov (f.eks. Airbnb-stil). Opret derefter en ny skjult fil .stylelintrc.jsonsom er Stylelints konfigurationsfil, der er ansvarlig for at indlæse vores foruddefinerede regler:

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

Lige nu er det eneste, der mangler, et NPM-script (eller scripts), der er erklæret i package.json-filen for at begynde at linting vores SCSS-filer. Her er mit forslag:

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

Som du kan se, har jeg erklæret, at scriptet indeholder -fix mulighed - denne skal bruges, før du skubber ændringer til repository.

Husk - det er en dårlig praksis at bruge -fix i dit CI-flow, for så bliver den kode, du sender til produktionen, ikke stylet korrekt i repository'et. Det er derfor, vi har brug for begge scripts.

Lad os teste vores linter ved at oprette en fil /assets/scss/styles.scss med noget indhold, f.eks:

krop {
                    baggrundsfarve: #fff;
}

npm run lint:scss

Du bør se noget i retning af dette i din konsol:

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

assets/scss/styles.scss

2:21 ✖ Forventet indrykning på 2 mellemrum indrykning

1 kilde kontrolleret

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

1 problem fundet

alvorlighedsniveau "fejl": 1

indrykning: 1

npm ERR! kode ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Afslut status 2

Det betyder faktisk, at vores liner virker!

Outputtet viser præcis, hvilken linje der forårsager en fejl, og beskriver det problem, der skal løses. Nogle problemer kan ikke løses automatisk, da de kræver en udviklers beslutning, men i de fleste tilfælde skal du bare køre den samme kommando med -fix mulighed, så lad os køre den.

npm run lint:scss:fix

Nu bør du se et grønt output uden fundne fejl:

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


1 kilde tjekket

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

0 problemer fundet

4. Tilføjelse af ESLint

Dette trin er næsten det samme som det foregående. Vi installerer ESLint, definerer nogle standardregler og erklærer to NPM-scripts, der kan kaldes - et til CI og et til pre-push. Lad os gå igennem dette!

Hvis du bruger NPM i dit daglige arbejde, vil du måske gerne installere ESLint globalt. Hvis du ikke gør det, kan du se installationsvejledningen i officielle dokumenter.

npm install -g eslint

Når eslint-kommandoen er tilgængelig på din maskine, skal du bare køre den i dit projekt:

eslint --init

Følg de yderligere instruktioner, der vises i din terminal, og tag et par projektbeslutninger som f.eks:

• Javascript eller TypeScript
• Airbnb-stil eller Google-stil
• konfigurationstype (JSON-fil, JS-fil eller inline i pakke.json)
• ES-moduler (import/eksport) eller kræver syntaks

På dette sted er det værd at skrive et par ord om kodeformateringsprogrammet Prettier. Den er fuldt standardiseret og kompatibel med de fleste kodeditorer (f.eks. VS Code). Prettier giver mange sæt af foruddefinerede regler for kodestyling, arbejder sammen med linters og kan være en stor støtte i jagten på topkvalitet i koden. For at forstå, hvad Prettier helt præcist er, skal du besøge dette sammenligning fra officielle dokumenter.

Hvis det er gjort, skal ESlint-konfigurationsfilen (f.eks. .eslintrc.json(afhængigt af hvad du har valgt før) bør vises i din rodmappe, et sted ved siden af .stylelintrc.json skabt før.

Nu skal vi definere scripts i pakke.json fil, på samme måde som for SCSS-filer:

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

Tillykke med det! ESLint er klar til brug lige nu. Lad os tjekke, om det fungerer korrekt. Opret /src/index.js fil med noget indhold:

console.log("noget");

Kør linter:

npm kør lint:js


Resultatet bør se sådan ud:

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

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

1:1 advarsel Uventet konsol-sætning no-console

✖ 1 problem (0 fejl, 1 advarsel)

Denne advarsel forsvinder ikke, når du bruger -fix mulighed, fordi linters påvirker ikke potentielt meningsfuld kode. De er kun til kodestyling, inklusive hvide mellemrum, nye linjer, semikolon, anførselstegn osv.

5. Definition af GitHub-arbejdsgange

GitHub-arbejdsgange er en ret veldokumenteret ting. Du er velkommen til at grave dybere i dette, men lige nu vil jeg implementere en simpel arbejdsgang til at lint'e vores kode efter push til remote repository (naturligvis hostet på GitHub).

Opret /.github/arbejdsgange mappe og ny kode-kvalitet-arbejdsgang.yml fil derinde, da GitHub-arbejdsgange skal defineres med YAML-filer.

For at køre et ordentligt workflow skal vi besvare et par spørgsmål:

• Hvornår vil vi køre vores workflow (ved push, ved pull request, ved merge osv.)?
• Vil vi udelukke nogle situationer (som push til branch master)?
• Hvilket miljø skal vi sætte op for at køre vores kommandoer korrekt (i dette eksempel - Node)?
• Skal vi installere afhængigheder? Hvis ja, hvordan skal vi så cache det?
• Hvilke skridt skal vi tage for at gennemføre kontrollen?

Efter nogle overvejelser og et par timers arbejde med docs-eksemplet .yml fil kan se sådan ud:

navn: Kodekvalitet

on: 'tryk'

jobs:
  kode-kvalitet:
    navn: Lint kildekode
    runs-on: ubuntu-latest
    trin:
    - bruger: actions/checkout@v1

    - navn: Opsætning af knudepunkt
      bruger: actions/setup-node@v1
      med:
        node-version: '12.1'

    - navn: Cache-afhængigheder
      bruger: actions/cache@v1
      med:
        sti: ./node_modules
        key: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        gendanne-nøgler: |
          $(( runner.OS ))-dependencies-$(( env.cache-name ))-
          $(( runner.OS ))-afhængigheder-
          $(( runner.OS ))-

    - navn: Installer afhængigheder
      kør: |
        npm-installation

    - navn: Lint-filer
      kør: |
        npm kør lint

GitHub leverer alle de miljømæssige ting, vi har brug for. I den sidste linje kører vi kommandoen npm kør lint som ikke var defineret før:

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

Bemærk, at jeg i vores arbejdsgang ikke bruger :fix kommandoer.

Når alle disse trin er udført, kan du nyde dette smukke output fra GitHub, før du fletter din Pull Request: