Pirmiausia kokybė! 5 paprasti žingsniai, kaip JavaScript projekte perbraižyti kodą naudojant "GitHub" darbo eigą

Ką turėtume daryti, kai projektas yra mažas arba klientas vis dar nežino, ar verta investuoti daugiau? Akivaizdu, kad Projekto MVP etapas, kodas stilius ar vienetiniai testai nėra svarbiausias prioritetas. Investuotojai paprastai nori turėti gerą produktas ir c'mon - jei jis veikia, jo nereikia testuoti, ar ne?

Tiesą sakant, turiu patirties programėlių kūrimas nuo nulio, net ir nenaudojant geriausios praktikos. Kai kurios verslo aplinkybės privertė mane ieškoti kompromiso tarp investuotojo biudžeto planų ir kūrėjo „gražių” dalykų sąrašo. Laimei, jei naudojatės "GitHub", daugumą dažniausiai pasitaikančių su kodo kokybe susijusių problemų galima išspręsti per kelias minutes.

Šiame straipsnyje parodysiu, kaip Node.js aplinkoje naudoti "GitHub" darbo eigą ir standartizuoti savo kodų bazę.

Kelios prielaidos prieš pradedant:

• Esate susipažinęs su NPM ir "Linux" konsole.
• Turite patirties su stiliaus preprocesoriais, modulių įkrovikliais, paketais ir kt.
• Žinote, kam skirti linteriai, ir tikrai norite juos naudoti savo projektuose.

1. Tipinė JavaScript projekto struktūra

Jei kada nors naudojote JS sistemos, pvz. Vue arba React, nesunkiai pastebėsite kai kuriuos bendrus dalykus, pvz:

• /src katalogą su visa jūsų JS logika ir komponentais,
• /testas katalogas, skirtas vienetiniams ir e2e testams,
• /turtas katalogas, kuriame yra stilių, paveikslėlių ir kt.

Net jei kalbame apie JavaScript projektą, mes dirbame Mazgas aplinka, todėl akivaizdu, kad taip pat turėtų būti kai kurie "Node" dalykai, pvz. package.json, package-lock.json ir /node_modules katalogą mūsų šakniniame kataloge.

Visi šie dalykai yra savo vietose - tai vadiname konvencija. Karkasai yra sukurti tam, kad būtų numatytos tam tikros pagrįstos konvencijos, todėl paprastai mums net nereikia rūpintis pradiniu projektavimo šablonu. Kadangi šiame pavyzdyje noriu paaiškinti kai kuriuos metodus, netaikysiu jokių gatavų sprendimų, pavyzdžiui, Vue CLI.

Laikas suprasti, kas slypi po visais šiais stebuklingais lint scenarijais!

2. Tipinio "Node" projekto išplėtimas

Norint pateikti aukštos kokybės sprendimus, kuriant naują projektą pirmiausia reikėtų pradėti nuo linterių. Sutelkime dėmesį į du linterius - stilių linterį Stylelint (*.scss) ir "ESLint" šaltinio failams (*.js). Abu šie linteriai yra prieinami NPM ir juos gana lengva konfigūruoti. Naudojant linters reikia pereiti diegimo procesą, pridėti konfigūracijos failus ir apibrėžti projekto scenarijus. Atlikime tai žingsnis po žingsnio.

3. Stiliaus "Stylelint" pridėjimas

Įdiegti "Stylelint" "Node" aplinkoje labai paprasta. Pagal oficialūs dokumentai, jums tereikia paleisti:

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

ir palaukite, kol jis bus baigtas.

stylelint-config-standard pateikia numatytuosius tinklinimo taisyklių rinkinius ir gali būti pakeistas bet kuriuo paketu, kuris geriau atitinka jūsų poreikius (pvz. Airbnb stilius). Tada sukurkite naują paslėptą failą .stylelintrc.json, kuris yra "Stylelint" konfigūracijos failas, atsakingas už iš anksto nustatytų taisyklių įkėlimą:

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

Dabar trūksta tik vieno dalyko - paketo.json faile deklaruoto NPM scenarijaus (arba scenarijų), kad būtų galima pradėti lintinguoti SCSS failus. Štai mano pasiūlymas:

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

Kaip matote, deklaravau scenarijų, kuriame yra -fiksas parinktį - ją reikia naudoti prieš perkeliant pakeitimus į saugyklą.

Atminkite, kad bloga praktika yra naudoti -fiksas CI sraute, nes tada kodas, kurį perduodate į gamybą, saugykloje nėra tinkamai stilizuojamas. Todėl mums reikia abiejų scenarijų.

Išbandykime savo linterį sukurdami failą /assets/scss/styles.scss su tam tikru turiniu, pvz:

kūnas {
                    fono spalva: #fff;
}

npm paleisti lint:scss

Konsolėje turėtumėte matyti štai tokį vaizdą:

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

assets/scss/styles.scss

2:21 ✖ Laukiama 2 tarpų įtraukos įtraukos

Patikrintas 1 šaltinis

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

Rasta 1 problema

sunkumo lygis "klaida": 1

Įstrižainė: 1

npm ERR! kodas ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Išėjimo būsena 2

Tai iš tikrųjų reiškia, kad mūsų linteris veikia!

Išvestyje tiksliai parodoma, kurioje eilutėje įvyko klaida, ir aprašoma problema, kurią reikia išspręsti. Kai kurių problemų negalima išspręsti automatiškai, nes reikia kūrėjo sprendimo, tačiau daugeliu atvejų tereikia paleisti tą pačią komandą su -fiksas parinktį, todėl paleiskime ją.

npm paleisti lint:scss:fix

Dabar turėtumėte matyti žalią išvestį be rastų klaidų:

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


Patikrintas 1 šaltinis

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

Rasta 0 problemų

4. ESLint pridėjimas

Šis žingsnis yra beveik toks pat kaip ir ankstesnis. Įdiegsime "ESLint", apibrėšime numatytąjį taisyklių rinkinį ir deklaruosime du NPM skriptus - vieną CI, kitą "pre-push". Pereikime per tai!

Jei kasdieniame darbe naudojate NPM, galbūt norėtumėte įdiegti "ESLint" visame pasaulyje. Jei ne, peržiūrėkite diegimo instrukcijas oficialūs dokumentai.

npm install -g eslint

Kai jūsų kompiuteryje yra eslint komanda, tiesiog paleiskite ją savo projekte:

eslint --init

Laikydamiesi tolesnių terminale rodomų instrukcijų, tiesiog priimkite kelis projekto sprendimus, pvz:

• Javascript arba TypeScript
• "Airbnb" ar "Google" stilius
• konfigūracijos tipą (JSON failas, JS failas arba eilutėje package.json)
• ES moduliai (importas/eksportas) arba reikalauti sintaksė

Šioje vietoje verta parašyti keletą žodžių apie kodo formatavimo priemonę Prettier. Jis visiškai standartizuotas ir suderinamas su daugeliu kodo redaktorių (pvz., VS Code). Prettier pateikia daugybę iš anksto nustatytų kodo stilizavimo taisyklių rinkinių, bendradarbiauja su linteriais ir gali būti puiki pagalba siekiant aukščiausios kodo kokybės. Norėdami suprasti, kas tiksliai yra Prettier, apsilankykite šioje svetainėje palyginimas iš oficialių dokumentų.

Jei tai padaryta, ESlint konfigūracijos failas (pvz. .eslintrc.json, (priklausomai nuo to, ką pasirinkote anksčiau), turėtų atsirasti jūsų šakniniame kataloge, kur nors šalia .stylelintrc.json sukurta anksčiau.

Dabar turime apibrėžti scenarijus package.json failą, kaip ir SCSS failus:

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

Sveikiname! "ESLint" jau galima naudoti. Patikrinkime, ar ji veikia teisingai. Sukurti /src/index.js failą su tam tikru turiniu:

console.log("kažkas");

Paleiskite linterį:

npm paleisti lint:js


Išvestis turėtų atrodyti taip:

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

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

1:1 įspėjimas Netikėtas konsolės teiginys no-console

✖ 1 problema (0 klaidų, 1 įspėjimas)

Šis įspėjimas neišnyks, jei naudosite -fiksas parinktį, nes linteriai neturi įtakos potencialiai reikšmingam kodui. Jie skirti tik kodo stilizacijai, įskaitant baltuosius tarpus, naująsias eilutes, kabutes, kabliataškius, kabutes ir t. t.

5. "GitHub" darbo eigos apibrėžimas

"GitHub" darbo eigos yra gana gerai dokumentuotas dalykas. Kviečiame gilintis į tai, bet kol kas įgyvendinsiu paprastą darbo eigą, skirtą mūsų kodui po išsiuntimo į nuotolinę saugyklą (aišku, talpinamą GitHub).

Sukurti /.github/workflows katalogą ir naują code-quality-workflow.yml failą, nes "GitHub" darbo eigos turi būti apibrėžtos naudojant YAML failus.

Norėdami paleisti tinkamą darbo eigą, turime atsakyti į keletą klausimų:

• Kada norime paleisti savo darbo eigą (siunčiant, ištraukiant užklausą, sujungiant ir t. t.)?
• Ar norime išskirti kai kuriuos atvejus (pvz., perkėlimą į pagrindinę šaką)?
• Kokią aplinką turime nustatyti, kad teisingai paleistume komandas (šiame pavyzdyje - "Node")?
• Ar reikia įdiegti priklausomybes? Jei taip, kaip turėtume tai padaryti?
• Kokius veiksmus turime atlikti, kad užbaigtume patikrinimą?

Po tam tikrų svarstymų ir kelių valandų darbo su dokumentais pavyzdys .yml failas gali atrodyti taip:

pavadinimas: Kodas kokybė

on: 'push

darbo vietos:
  code-quality:
    vardas: Lint source code
    runs-on: ubuntu-latest
    steps:
    - Naudoja: actions/checkout@v1

    - pavadinimas: Setup Node
      uses: actions/setup-node@v1
      su:
        node-version: '12.1'

    - pavadinimas: Cache dependencies
      uses: actions/cache@v1
      with:
        su: kelias: ./node_modules
        raktas: $((( runner.OS ))-dependencies-$((( hashFiles('**/package-lock.json') ))
        restore-keys: |
          $(( runner.OS ))-priklausomybės-$(( env.cache-name ))-
          $(( runner.OS ))-priklausomybės-
          $(( runner.OS ))-

    - pavadinimas: Įdiegti priklausomybes
      paleisti: |
        npm install

    - vardas: Lint failai
      paleisti: |
        npm run lint

"GitHub" teikia visą mums reikalingą aplinkos medžiagą. Paskutinėje eilutėje paleidžiame komandą npm paleisti lint kuris anksčiau nebuvo apibrėžtas:

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

Atkreipkite dėmesį, kad mūsų darbo eigoje nenaudoju :fix komandų.

Atlikę visus šiuos veiksmus, prieš suliedami savo "Pull Request" užklausą galėsite mėgautis šia gražia "GitHub" išvestimi: