Kvalitet først! 5 enkle trinn for å lint koden din med GitHub-arbeidsflyter i JavaScript-prosjektet

Hva skal vi gjøre når prosjekt er liten, eller vet kunden fortsatt ikke om det er verdt å investere mer? Det er åpenbart at på MVP-fasen av prosjektet, kode styling eller enhetstester er ikke førsteprioritet. Investorer ønsker vanligvis å ha en god produkt og kom igjen - hvis det fungerer, trenger det vel ikke å testes?

Jeg har faktisk litt erfaring med bygge apper fra bunnen avselv uten å bruke beste praksis i utgangspunktet. Noen forretningsmessige omstendigheter tvang meg til å lete etter et kompromiss mellom en investors budsjettplaner og utviklerens "nice-to-have"-liste. Heldigvis kan de fleste vanlige problemer knyttet til kodekvalitet løses på noen få minutter hvis du bruker GitHub.

I denne artikkelen skal jeg vise deg hvordan du bruker GitHub-arbeidsflyter i Node.js-miljøet for å standardisere kodebasen din.

Noen forutsetninger før vi begynner:

• Du er kjent med NPM og Linux-konsollen.
• Du har litt erfaring med stilpreprosessorer, modullastere, bundlere osv.
• Du vet hva linters er til for og vil gjerne bruke dem i prosjektene dine.

1. Typisk JavaScript-prosjektstruktur

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

• /src katalogen med all JS-logikk og alle komponenter,
• /test katalogen for enhets- og e2e-tester,
• /aktiva katalogen for stiler, bilder osv.

Selv om vi snakker om JavaScript prosjekt, jobber vi i Knutepunkt miljø, så det bør selvsagt også være noen Node-ting som package.json, package-lock.json og /node_modules katalogen i rotkatalogen vår.

Alle disse tingene er på sin plass - det er det vi kaller konvensjon. Rammeverk er oppfunnet for å gi noen rimelige konvensjoner, så vanligvis trenger vi ikke engang å bry oss om det opprinnelige designmønsteret. I dette eksemplet vil jeg forklare noen tilnærminger, og jeg vil ikke bruke noen ferdige løsninger som Vue CLI.

På tide å forstå hva som skjuler seg bak alle disse magiske lo-skriptene!

2. Utvidelse av det typiske Node-prosjektet

For å kunne tilby løsninger av høy kvalitet er linters det første vi bør begynne med når vi setter opp et nytt prosjekt. La oss fokusere på to lintere - Stylelint for stiler (*.scss) og ESLint for kildefiler (*.js). Begge disse linterne er tilgjengelige på NPM og er ganske enkle å konfigurere. Bruk av linters krever at du går gjennom installasjonsprosessen, legger til konfigurasjonsfiler og definerer prosjektskript. La oss gjøre det trinn for trinn.

3. Legge til Stylelint

Installasjonen av Stylelint i Node-miljøet er veldig enkel. I henhold til offisielle dokumenter...trenger du bare å løpe:

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

og vent til den er ferdig.

stylelint-config-standard inneholder et standard sett med linting-regler og kan erstattes med en pakke som passer bedre til dine behov (f.eks. Airbnb-stil). Opprett deretter en ny skjult fil .stylelintrc.jsonsom er Stylelints konfigurasjonsfil, som er ansvarlig for å laste inn de forhåndsdefinerte reglene våre:

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

Akkurat nå er det eneste som mangler noe NPM-skript (eller skript) som er deklarert i package.json-filen for å starte linting av SCSS-filene våre. Her er mitt forslag:

"skript": {
    "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 deklarert skriptet som inneholder -fiks alternativet - dette alternativet skal brukes før du skyver endringer til depotet.

Husk - det er dårlig praksis å bruke -fiks i CI-flyten, for da blir ikke koden du sender til produksjon, stylet riktig i repositoryet. Det er derfor vi trenger begge manusene.

La oss teste linteren vår ved å opprette en fil /assets/scss/styles.scss med noe innhold, for eksempel:

body {
                    bakgrunnsfarge: #fff;
}

npm kjør lint:scss

Du bør se noe slikt i konsollen:

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

assets/scss/styles.scss

2:21 ✖ Forventet innrykk på 2 mellomrom innrykk

1 kilde sjekket

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

1 problem funnet

alvorlighetsgrad "feil": 1

innrykk 1

npm ERR! kode ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Avslutt status 2

Dette betyr faktisk at linteren vår fungerer!

Utdataene viser nøyaktig hvilken linje som forårsaker en feil, og beskriver problemet som skal løses. Noen problemer kan ikke løses automatisk, da de krever en beslutning fra en utvikler, men i de fleste tilfeller trenger du bare å kjøre den samme kommandoen med -fiks alternativet, så la oss kjøre det.

npm run lint:scss:fix

Nå skal du se en grønn utgang med ingen feil funnet:

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


1 kilde sjekket

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

0 problemer funnet

4. Legge til ESLint

Dette trinnet er nesten det samme som det forrige. Vi skal installere ESLint, definere noen standard regelsett og deklarere to kaldbare NPM-skript - ett for CI, ett for pre-push. La oss gå gjennom dette!

Hvis du bruker NPM i ditt daglige arbeid, ønsker du kanskje å installere ESLint globalt. Hvis du ikke gjør det, kan du sjekke installasjonsinstruksjonene i offisielle dokumenter.

npm install -g eslint

Når eslint-kommandoen er tilgjengelig på maskinen din, er det bare å kjøre den i prosjektet ditt:

eslint --init

Følg instruksjonene som vises i terminalen, og ta noen få prosjektbeslutninger, for eksempel

• Javascript eller TypeScript
• Airbnb-stil eller Google-stil
• konfigurasjonstype (JSON-fil, JS-fil eller inline i package.json)
• ES-moduler (import/eksport) eller krever syntaks

På dette stedet er det verdt å skrive et ord om kodeformater som heter Prettier. Det er fullt standardisert og kompatibelt med de fleste kodeditorer (f.eks. VS Code). Prettier gir mange sett med forhåndsdefinerte regler for kodestyling, samarbeider med linters og kan være en god støtte i jakten på topp kvalitet på koden. For å forstå hva Prettier egentlig er, besøk denne sammenligning fra offisielle dokumenter.

Hvis det er gjort, vil ESlint-konfigurasjonsfilen (f.eks. .eslintrc.json(avhengig av hva du har valgt tidligere) skal vises i rotkatalogen din, et sted ved siden av .stylelintrc.json opprettet før.

Nå må vi definere skript i package.json fil, på samme måte som for SCSS-filer:

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

Gratulerer med dagen! ESLint er klar til bruk nå. La oss sjekke om det fungerer som det skal. Opprett /src/index.js fil med noe innhold:

console.log("noe");

Kjør linter:

npm kjør lint:js


Utdataene skal se slik ut:

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

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

1:1 warning Uventet konsoll-setning no-console

✖ 1 problem (0 feil, 1 advarsel)

Denne advarselen forsvinner ikke etter bruk av -fiks alternativet, fordi linters påvirker ikke potensielt meningsfull kode. De er kun for kodestyling, inkludert hvite mellomrom, nye linjer, semikolon, anførselstegn osv.

5. Definere GitHub-arbeidsflyter

GitHub-arbeidsflyter er en ganske veldokumentert greie. Du er velkommen til å grave dypere i dette, men for nå, jeg skal implementere en enkel arbeidsflyt for å lint koden vår etter push til remote repository (åpenbart, vert på GitHub).

Opprett /.github/arbeidsflyter katalog og ny kode-kvalitet-arbeidsflyt.yml filen der, ettersom GitHub-arbeidsflyter må defineres med YAML-filer.

For å kunne kjøre en ordentlig arbeidsflyt må vi svare på noen spørsmål:

• Når ønsker vi å kjøre arbeidsflyten vår (ved push, ved pull request, ved sammenslåing osv.)?
• Ønsker vi å ekskludere noen situasjoner (som push til master-grenen)?
• Hvilket miljø må vi konfigurere for å kjøre kommandoene våre riktig (i dette eksempelet - Node)?
• Må vi installere avhengigheter? I så fall, hvordan skal vi mellomlagre dem?
• Hvilke skritt må vi ta for å fullføre sjekken?

Etter noen overveielser og noen timers arbeid med docs eksempel .yml filen kan se slik ut:

navn: Kodekvalitet

on: 'push'

jobber
  code-quality:
    navn: Lint kildekode
    runs-on: ubuntu-latest
    steps:
    - bruker: actions/checkout@v1

    - navn: Setup Node
      bruker: actions/setup-node@v1
      med
        node-version: '12.1'

    - navn: Cache-avhengigheter
      bruker: actions/cache@v1
      with:
        path: ./node_modules
        key: $((( runner.OS ))-dependencies-$((( hashFiles('**/package-lock.json') ))
        restore-keys: |
          $((( runner.OS ))-dependencies-$(( env.cache-name ))-
          $((( runner.OS ))-avhengigheter-
          $(( runner.OS ))-

    - navn: Installer avhengigheter
      kjør: |
        npm install

    - navn: Lint-filer
      run: |
        npm run lint

GitHub tilbyr alle miljømessige ting vi trenger. I den siste linjen kjører vi kommandoen npm kjør lint som ikke var definert tidligere:

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

Merk at i vår arbeidsflyt bruker jeg ikke :fix kommandoer.

Når alle disse trinnene er gjort, kan du nyte denne vakre utdataen fra GitHub før du slår sammen Pull Request: