Kvaliteet kõigepealt! 5 lihtsat sammu oma koodi lintimiseks GitHubi töövoogude abil JavaScript projektis

Mida me peaksime tegema, kui projekt on väike või ei tea klient ikka veel, kas tasub rohkem investeerida? Ilmselt on Projekti MVP etapp, kood stiili- või ühiktestid ei ole esmatähtis. Investorid tahavad tavaliselt head toode ja kuule - kui see töötab, siis ei ole vaja katsetada, eks ole?

Tegelikult on mul mõningaid kogemusi rakenduste loomine nullist, isegi ilma parimate tavade kasutamiseta. Mõned ärilised asjaolud sundisid mind otsima kompromissi investori eelarveplaanide ja arendaja "nice-to-have" nimekirja vahel. Õnneks, kui kasutate GitHubi, saab enamiku koodi kvaliteediga seotud tavapärastest probleemidest lahendada mõne minutiga.

Selles artiklis näitan teile, kuidas kasutada GitHubi töövooge Node.js keskkonnas oma koodibaasi standardiseerimiseks.

Mõned eeldused enne alustamist:

• Te olete tuttav NPM-i ja Linuxi konsooliga.
• Teil on mõningane kogemus stiilipreprotsessorite, moodulite laadijate, bundlerite jne kasutamisega.
• Te teate, milleks on linterid ja tahate neid oma projektides tõesti kasutada.

1. Tüüpiline JavaScript projekti struktuur

Kui te olete kunagi kasutanud mõnda JS raamistikku nagu Vue või React, võite hõlpsasti märgata mõningaid ühiseid asju nende vahel, nt:

• /src kataloogi kogu teie JS-loogika ja komponentidega,
• /test kataloogi üksuse ja e2e testide jaoks,
• /varad kataloogi stiilide, piltide jne jaoks.

Isegi kui me räägime JavaScript projekt, me töötame Sõlme keskkonda, nii et ilmselt peaks olema ka mõned Node'i asjad nagu package.json, package-lock.json ja /node_modules kataloogi meie juurkataloogis.

Kõik need asjad on oma koha peal - seda me nimetame konventsioon. Raamistikud on leiutatud selleks, et pakkuda mõningaid mõistlikke konventsioone, nii et tavaliselt ei ole meil vaja isegi hoolida esialgsest disainimustrist. Kuna selles näites tahan selgitada mõningaid lähenemisviise, ei hakka ma rakendama mingeid valmis lahendusi nagu Vue CLI.

Aeg on aru saada, mis peitub kõigi nende maagiliste lintide all!

2. Tüüpilise Node projekti laiendamine

Kvaliteetsete lahenduste pakkumiseks on linterid esimene asi, millest me peaksime uue projekti loomisel alustama. Keskendume kahele linterile - Stylelint stiilide jaoks (*.scss) ja ESLint lähtefailide jaoks (*.js). Mõlemad linterid on saadaval NPM-is ja neid on üsna lihtne konfigureerida. Linterite kasutamine nõuab paigaldusprotsessi läbimist, konfigfailide lisamist ja projekti skriptide määratlemist. Teeme seda samm-sammult.

3. Stylelindi lisamine

Stylelint'i paigaldamine Node'i keskkonda on väga lihtne. Vastavalt ametlikud dokumendid, peate lihtsalt jooksma:

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

ja oodake, kuni see on valmis.

stylelint-config-standard pakub vaikimisi lintingu reegleid ja selle võib asendada mis tahes paketiga, mis sobib teie vajadustele paremini (nt. Airbnb stiilis). Seejärel looge uus peidetud fail .stylelintrc.json, mis on Stylelint'i konfiguratsioonifail, mis vastutab meie eelnevalt määratletud reeglite laadimise eest:

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

Praegu on ainus puuduv asi mõni NPM skript (või skriptid), mis on deklareeritud package.json failis, et alustada meie SCSS-failide lintingut. Siin on minu ettepanek:

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

Nagu näete, olen deklareerinud skripti, mis sisaldab -fix valik - seda tuleb kasutada enne muudatuste saatmist repositooriumi.

Pidage meeles - on halb tava kasutada -fix teie CI-voolus, sest siis ei ole kood, mille te tootmisse edastate, repositooriumis õigesti kujundatud. Seepärast ongi meil vaja mõlemat skripti.

Testime oma linterit, luues faili /assets/scss/styles.scss mingi sisuga, nagu:

body {
                    background-color: #fff;
}

npm run lint:scss

Teie konsoolis peaks olema näha midagi sellist:

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

assets/scss/styles.scss

2:21 ✖ Oodatud taandumine 2 tühikut taandumine

1 allikas kontrollitud

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

1 probleem leitud

raskusaste "error": 1

taandumine: 1

npm ERR! kood ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Väljalangemise staatus 2

See tähendab tegelikult, et meie linter töötab!

Väljund näitab täpselt, milline rida põhjustab vea ja kirjeldab probleemi lahendamist. Mõned probleemid ei ole automaatselt parandatavad, sest need vajavad arendaja otsust, kuid enamikul juhtudel tuleb lihtsalt käivitada sama käsk koos järgmisega -fix võimalus, nii et käivitame selle.

npm run lint:scss:fix

Nüüd peaksite nägema rohelist väljundit, kus vigu ei ole leitud:

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


1 kontrollitud allikas

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

0 leitud probleemi

4. ESLint lisamine

See samm on peaaegu sama, mis eelmine. Installeerime ESLint'i, defineerime mõned vaikimisi reeglid ja deklareerime kaks kutsutavat NPM skripti - ühe CI jaoks ja ühe pre-push'i jaoks. Käime selle läbi!

Kui kasutate NPM-i oma igapäevatöös, siis võib-olla soovite ESLint'i globaalselt paigaldada. Kui te seda ei tee, vaadake palun paigaldusjuhiseid dokumendis ametlikud dokumendid.

npm install -g eslint

Kui eslint käsk on teie masinas saadaval, käivitage see lihtsalt oma projektis:

eslint --init

Järgides edasisi juhiseid, mis kuvatakse teie terminalis, tehke lihtsalt mõned projektiotsused, nagu:

• Javascript või TypeScript
• Airbnb stiilis või Google'i stiilis
• konfiguratsioonitüüp (JSON-fail, JS-fail või inline in package.json)
• ES-moodulid (import/eksport) või nõuda süntaks

Siinkohal tasub kirjutada paar sõna koodi vormindajast nimega Prettier. See on täielikult standardiseeritud ja ühildub enamiku koodiredaktoritega (nt VS Code). Prettier pakub palju eeldefineeritud koodi kujundamise reegleid, teeb koostööd linteritega ja võib olla suureks toeks koodi tippkvaliteedi tagaajamisel. Selleks, et mõista, mis Prettier täpselt on, külastage seda. võrdlus ametlikest dokumentidest.

Kui see on tehtud, siis ESlint config faili (nt. .eslintrc.json, sõltuvalt sellest, mida te varem valisite) peaks ilmuma teie juurkataloogi, kusagil kõrval oleva .stylelintrc.json loodud enne.

Nüüd peame defineerima skriptid package.json faili, nagu SCSS-failide puhul:

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

Palju õnne! ESLint on kohe kasutusvalmis. Kontrollime, kas see töötab õigesti. Looge /src/index.js faili mingi sisuga:

console.log("midagi");

Käivita linter:

npm run lint:js


Väljund peaks välja nägema selline:

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

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

1:1 hoiatus Ootamatu konsooli avaldis no-console

✖ 1 probleem (0 viga, 1 hoiatus)

See hoiatus ei kao pärast kasutamist -fix võimalus, sest linterid ei mõjuta potentsiaalselt mõttekat koodi. Need on ainult koodi kujundamiseks., sealhulgas tühikud, read, semikoolonid, jutumärgid jne.

5. GitHubi töövoogude määratlemine

GitHubi töövood on üsna hästi dokumenteeritud asi. Võite vabalt süveneda sellesse, kuid praegu rakendan ma lihtsa töövoo, et meie koodi pärast push'i kaugrepositooriumi (ilmselt GitHubis majutatud) lint'ile viia.

Loo /.github/workflows kataloogi ja uue code-quality-workflow.yml faili, kuna GitHubi töövood tuleb defineerida YAML-failide abil.

Korraliku töövoo käivitamiseks peame vastama mõnele küsimusele:

• Millal me tahame oma töövoogu käivitada (push, pull request, merge jne)?
• Kas me tahame välistada mõned olukorrad (näiteks push to branch master)?
• Millise keskkonna me peame seadistama, et meie käske õigesti käivitada (antud näites - Node)?
• Kas meil on vaja paigaldada sõltuvusi? Kui jah, siis kuidas peaksime seda vahemällu salvestama?
• Milliseid samme peame kontrolli lõpuleviimiseks tegema?

Pärast mõningaid kaalutlusi ja paar tundi tööd dokumentidega näiteks .yml fail võib välja näha selline:

nimi: Koodikvaliteet

on: 'push'

tööd:
  koodikvaliteet:
    name: Lint source code
    töötab: ubuntu-latest
    sammud:
    - kasutab: actions/checkout@v1

    - nimi: Setup Node
      kasutab: actions/setup-node@v1
      with:
        node-version: '12.1'

    - name: Cache dependencies
      kasutab: 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 ))-dependencies-
          $(( runner.OS ))-

    - name: Paigaldada sõltuvused
      run: |
        npm install

    - nimi: Lint-failid
      run: |
        npm run lint

GitHub pakub kõiki vajalikke keskkonnaalaseid asju. Viimases reas käivitame käsu npm run lint mida varem ei olnud määratletud:

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

Pange tähele, et meie töövoos ma ei kasuta :fix käsud.

Kui kõik need sammud on tehtud, saate nautida seda ilusat väljundit GitHubist enne Pull Request'i ühendamist: