Laatu ensin! 5 helppoa vaihetta koodin niputtamiseen GitHub-työnkulkujen avulla JavaScript-projektissa.

Mitä meidän pitäisi tehdä, kun projekti on pieni tai asiakas ei vielä tiedä, kannattaako siihen investoida enemmän? On selvää, että Hankkeen MVP-vaihe, koodi muotoilu tai yksikkötestit eivät ole ensisijaisia. Sijoittajat haluavat yleensä hyvän tuote ja jos se toimii, sitä ei tarvitse testata, eikö niin?

Itse asiassa minulla on jonkin verran kokemusta sovellusten rakentaminen tyhjästäjopa ilman parhaita käytäntöjä. Eräät liiketoimintaolosuhteet pakottivat minut etsimään kompromissia sijoittajan budjettisuunnitelmien ja rakennuttajan "nice-to-have" -listan väliltä. Onneksi jos käytät GitHubia, useimmat yleisimmät koodin laatuun liittyvät ongelmat voidaan ratkaista muutamassa minuutissa.

Tässä artikkelissa näytän, miten voit käyttää GitHub-työnkulkuja Node.js-ympäristössä koodipohjan standardoimiseksi.

Muutamia oletuksia ennen kuin aloitamme:

• Tunnet NPM:n ja Linux-konsolin.
• Sinulla on jonkin verran kokemusta tyylin esikäsittelijöistä, moduulinlataajista, bundlerista jne.
• Tiedät, mitä varten linterit ovat ja haluat todella käyttää niitä projekteissasi.

1. Tyypillinen JavaScript-projektin rakenne

Jos olet koskaan käyttänyt joitakin JS-kehyksiä kuten Vue tai React, voit helposti havaita joitakin yhteisiä asioita niiden välillä, esimerkiksi:

• /src hakemistoon, jossa on kaikki JS-logiikkasi ja -komponenttisi,
• /testi hakemistoon yksikkö- ja e2e-testejä varten,
• /varat hakemistoon tyylejä, kuvia jne. varten.

Vaikka puhumme JavaScript projektissa työskentelemme Solmu ympäristössä, joten ilmeisesti siellä pitäisi olla myös joitakin Node-juttuja, kuten package.json, package-lock.json ja /node_modules luettelon juurihakemistossamme.

Kaikki nämä asiat ovat omalla paikallaan - sitä me kutsumme nimellä yleissopimus. Kehykset on keksitty tarjoamaan joitakin järkeviä konventioita, joten yleensä meidän ei tarvitse edes välittää alkuperäisestä suunnittelumallista. Koska tässä esimerkissä haluan selittää joitakin lähestymistapoja, en käytä mitään valmiita ratkaisuja, kuten Vue CLI:tä.

On aika ymmärtää, mitä kaikkien näiden maagisten nukkausskriptien alla piilee!

2. Tyypillisen Node-projektin laajentaminen

Laadukkaiden ratkaisujen tarjoaminen edellyttää, että uutta hanketta perustettaessa on ensimmäiseksi aloitettava linterit. Keskitytään kahteen linteriin - Stylelint tyyleille (*.scss) ja ESLint lähdetiedostoille (*.js). Molemmat näistä lintereistä ovat saatavilla NPM:ssä, ja ne on melko helppo konfiguroida. Linterien käyttäminen vaatii asennusprosessin läpikäymistä, konfigurointitiedostojen lisäämistä ja projektiskriptien määrittelyä. Tehdään se vaihe vaiheelta.

3. Stylelintin lisääminen

Stylelintin asennus Node-ympäristöön on todella yksinkertaista. Mukaan viralliset asiakirjatsinun tarvitsee vain juosta:

npm install --save-dev stylelint stylelint-config-standardi

ja odota, että se on valmis.

stylelint-config-standard tarjoaa oletusarvoisen joukon niputussääntöjä, ja se voidaan korvata millä tahansa paketilla, joka sopii tarpeisiisi paremmin (esim. Airbnb-tyyliin). Luo sitten uusi piilotettu tiedosto .stylelintrc.json, joka on Stylelintin konfigurointitiedosto, joka vastaa ennalta määritettyjen sääntöjemme lataamisesta:

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

Juuri nyt ainoa puuttuva asia on jokin NPM-skripti (tai skriptit), joka on ilmoitettu package.json-tiedostossa, jotta SCSS-tiedostot voidaan aloittaa niputtaminen. Tässä on ehdotukseni:

"skriptit": {
    "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"
}

Kuten näet, olen ilmoittanut skriptin sisältävän -fix -vaihtoehto - tätä käytetään ennen muutosten siirtämistä arkistoon.

Muista - on huono käytäntö käyttää -fix CI-virtauksessa, koska silloin tuotantoon siirtämääsi koodia ei ole tyylitelty oikein arkistossa. Siksi tarvitsemme molemmat käsikirjoitukset.

Testaamme linteriä luomalla tiedoston /assets/scss/styles.scss jossa on sisältöä, kuten:

body {
                    background-color: #fff;
}

npm run lint:scss

Konsolissasi pitäisi näkyä jotain tällaista:

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

assets/scss/styles.scss

2:21 ✖ Odotettu sisennys 2 välilyöntiä sisennys

1 lähde tarkistettu

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

1 ongelma löydetty

vakavuustaso "virhe": 1

sisennys: 1

npm ERR! koodi ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Poistumistila 2

Tämä tarkoittaa sitä, että linterimme toimii!

Tulosteessa näkyy tarkalleen, mikä rivi aiheuttaa virheen, ja siinä kuvataan ratkaistava ongelma. Joitakin ongelmia ei voi korjata automaattisesti, koska ne vaativat kehittäjän päätöksen, mutta useimmissa tapauksissa sinun tarvitsee vain ajaa sama komento komennolla -fix vaihtoehto, joten ajetaan se.

npm run lint:scss:fix

Nyt sinun pitäisi nähdä vihreä tuloste, jossa ei ole virheitä:

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


1 lähde tarkistettu

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

0 ongelmaa löydetty

4. ESLintin lisääminen

Tämä vaihe on lähes sama kuin edellinen. Asennamme ESLintin, määrittelemme joitakin oletussääntöjä ja ilmoitamme kaksi kutsuttavaa NPM-skriptiä - yhden CI:tä ja yhden pre-pushia varten. Käydään tämä läpi!

Jos käytät NPM:ää päivittäisessä työssäsi, ehkä haluat asentaa ESLintin globaalisti. Jos et halua, tutustu asennusohjeisiin osoitteessa viralliset asiakirjat.

npm install -g eslint

Kun eslint-komento on käytettävissä koneellasi, suorita se projektissasi:

eslint --init

Kun olet noudattanut päätelaitteessa näkyviä lisäohjeita, tee vain muutama projektipäätös, kuten:

• Javascript tai TypeScript
• Airbnb:n tai Googlen tyyliin
• konfiguraatiotyyppi (JSON-tiedosto, JS-tiedosto tai inline in package.json)
• ES-moduulit (tuonti/vienti) tai vaativat syntaksi

Tässä paikassa on syytä kirjoittaa sana koodin muotoilijasta nimeltä Prettier. Se on täysin standardoitu ja yhteensopiva useimpien koodieditoreiden (esim. VS Code) kanssa. Prettier tarjoaa monia valmiita koodin muotoilusääntöjä, tekee yhteistyötä linterien kanssa ja voi olla suuri tuki koodin huippulaadun tavoittelussa. Jos haluat ymmärtää, mikä Prettier tarkalleen ottaen on, käy tässä osoitteessa. vertailu virallisista asiakirjoista.

Jos se on tehty, ESlintin konfigurointitiedosto (esim. .eslintrc.jsonriippuen siitä, mitä olet valinnut aiemmin) pitäisi näkyä juurihakemistossasi, jossain seuraavassa paikassa. .stylelintrc.json luotu aiemmin.

Nyt meidän on määriteltävä skriptit package.json tiedosto, kuten SCSS-tiedostotkin:

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

Onneksi olkoon! ESLint on nyt käyttövalmis. Tarkistetaan, toimiiko se oikein. Luo /src/index.js tiedosto, jossa on jotain sisältöä:

console.log("jotain");

Suorita linteri:

npm run lint:js


Tuloksen pitäisi näyttää tältä:

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

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

1:1 warning Odottamaton konsoli-lauseke no-console

✖ 1 ongelma (0 virhettä, 1 varoitus)

Tämä varoitus ei katoa sen jälkeen, kun olet käyttänyt -fix vaihtoehto, koska linterit eivät vaikuta potentiaalisesti mielekkääseen koodiin. Ne ovat vain koodin muotoilua varten., mukaan lukien välilyönnit, uudet viivat, puolipisteet, lainausmerkit jne.

5. GitHub-työnkulkujen määrittäminen

GitHub-työnkulut ovat melko hyvin dokumentoitu asia. Voit vapaasti kaivaa syvemmälle tähän, mutta nyt aion toteuttaa yksinkertaisen työnkulun, jolla koodimme voidaan niputtaa sen jälkeen, kun se on siirretty etätietovarastoon (ilmeisesti GitHubissa).

Luo /.github/työnkulut hakemisto ja uusi code-quality-workflow.yml tiedostoa, koska GitHub-työnkulut on määriteltävä YAML-tiedostojen avulla.

Jotta työnkulku toimisi kunnolla, meidän on vastattava muutamaan kysymykseen:

• Milloin haluamme suorittaa työnkulun (push, pull request, merge jne.)?
• Haluammeko sulkea pois joitakin tilanteita (kuten push to branch master)?
• Minkä ympäristön meidän on asetettava, jotta komentomme voidaan suorittaa oikein (tässä esimerkissä - Node)?
• Pitääkö meidän asentaa riippuvuudet? Jos on, miten meidän pitäisi tallentaa se välimuistiin?
• Mitä toimenpiteitä meidän on toteutettava tarkastuksen loppuun saattamiseksi?

Joidenkin näkökohtien ja muutaman tunnin työn jälkeen docs esimerkki .yml tiedosto voi näyttää tältä:

nimi: Koodin laatu

on: 'push'

jobs:
  Laatu: Code-quality:
    name: Lint source code
    Käytössä: ubuntu-latest
    vaiheet:
    - uses: actions/checkout@v1

    - nimi: Setup Node
      käyttää: actions/setup-node@v1
      with:
        12.1'.

    - name: Cache-riippuvuudet
      käyttää: actions/cache@v1
      with:
        /node_modules
        avain: $(( runner.OS ))-dependencies-$((( hashFiles('**/package-lock.json') ))
        restore-keys: |
          $(( runner.OS ))-dependencies-$(( env.cache-name ))-
          $(( runner.OS ))-dependencies- $(( runner.OS ))-dependencies-
          $(( runner.OS ))- -

    - name: Asenna riippuvuudet
      run: |
        npm install

    - name: Lint-tiedostot
      run: |
        npm run lint

GitHub tarjoaa kaikki tarvitsemamme ympäristötuotteet. Viimeisellä rivillä suoritamme komennon npm run lint jota ei ollut määritelty aiemmin:

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

Huomaa, että meidän työnkulussamme en käytä :fix komentoja.

Kun kaikki nämä vaiheet on tehty, voit nauttia tästä kauniista GitHubin tulosteesta ennen Pull Requestin yhdistämistä: