Kvalitāte ir pirmajā vietā! 5 vienkārši soļi, lai JavaScript projektā uzlabotu kodu ar GitHub darbplūsmām

Ko mums vajadzētu darīt, kad projekts ir mazs vai klients vēl nezina, vai ir vērts ieguldīt vairāk? Acīmredzot, pie Projekta MVP posms, kods stila vai vienības testi nav galvenā prioritāte. Investori parasti vēlas, lai būtu labs produkts un c'mon - ja tas darbojas, tas nav nepieciešams testēt, vai ne?

Patiesībā man ir zināma pieredze lietotņu veidošana no nulles, pat tad, ja vispirms netiek izmantota labākā prakse. Daži biznesa apstākļi lika man meklēt kompromisu starp investora budžeta plāniem un izstrādātāja „patīkamo” sarakstu. Par laimi, ja izmantojat GitHub, lielāko daļu biežāk sastopamo ar koda kvalitāti saistīto problēmu var atrisināt dažu minūšu laikā.

Šajā rakstā es jums parādīšu, kā izmantot GitHub darbplūsmas Node.js vidē, lai standartizētu savu kodu bāzi.

Daži pieņēmumi, pirms sākam:

• Jūs pārzināt NPM un Linux konsole.
• Jums ir zināma pieredze ar stila pirmprocesoriem, moduļu ielādētājiem, komplektētājiem u. c.
• Jūs zināt, kam ir paredzēti linteri, un patiešām vēlaties tos izmantot savos projektos.

1. Tipiska JavaScript projekta struktūra

Ja esat kādreiz izmantojis kādu JS ietvarstruktūras, piemēram. Vue vai React, jūs varat viegli pamanīt dažas kopīgas lietas, piemēram:

• /src direktoriju ar visu jūsu JS loģiku un komponentēm,
• /tests direktoriju vienības un e2e testiem,
• /aktīvi stilu, attēlu utt. direktoriju.

Pat ja mēs runājam par JavaScript projektu, mēs strādājam Mezgls vide, tāpēc acīmredzot ir jābūt arī Node sīkumiem, piemēram. package.json, package-lock.json un /node_modules katalogs mūsu saknes direktorijā.

Visas šīs lietas ir savās vietās - to mēs saucam par. konvencija. Rāmji ir radīti, lai nodrošinātu dažas saprātīgas konvencijas, tāpēc parasti mums pat nav nepieciešams rūpēties par sākotnējo dizaina modeli. Tā kā šajā piemērā es vēlos izskaidrot dažas pieejas, es nepiemērošu nekādus gatavus risinājumus, piemēram, Vue CLI.

Laiks saprast, kas slēpjas zem visiem šiem maģiskajiem lint skriptiem!

2. Tipiskā Node projekta paplašināšana

Lai nodrošinātu augstas kvalitātes risinājumus, linteri ir pirmā lieta, ar ko jāsāk jauna projekta izveide. Pievērsīsim uzmanību diviem linteriem - stilu linteram Stylelint (*.scss) un ESLint avota failiem (*.js). Abi šie linteri ir pieejami NPM un ir diezgan viegli konfigurējami. Lietojot linterus, ir jāiziet instalēšanas process, jāpievieno konfigurācijas faili un jādefinē projekta skripti. Izdarīsim to soli pa solim.

3. Stylelint pievienošana

Stylelint instalēšana Node vidē ir ļoti vienkārša. Saskaņā ar oficiālie dokumenti, jums vienkārši jāskrien:

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

un pagaidiet, līdz tas būs pabeigts.

stylelint-config-standard nodrošina standartnoteikumu kopumu, un to var aizstāt ar jebkuru pakotni, kas labāk atbilst jūsu vajadzībām (piem. Airbnb stilā). Tad izveidojiet jaunu slēpto failu .stylelintrc.json, kas ir Stylelint konfigurācijas fails, kurš ir atbildīgs par mūsu iepriekš definēto noteikumu ielādēšanu:

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

Šobrīd vienīgais, kā pietrūkst, ir kāds NPM skripts (vai skripti), kas deklarēts package.json failā, lai sāktu mūsu SCSS failu atpazīšanu. Lūk, mans priekšlikums:

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

Kā redzat, es esmu deklarējis skriptu, kas satur -fix opcija - šī opcija ir jāizmanto pirms izmaiņu ievietošanas repozitorijā.

Atcerieties, ka ir nepareiza prakse izmantot -fix savā CI plūsmā, jo tad kods, ko nododat produkcijai, repozitorijā netiek pareizi stilizēts. Tāpēc mums ir nepieciešami abi scenāriji.

Izmēģināsim mūsu linteri, izveidojot failu /assets/scss/styles.scss ar noteiktu saturu, piemēram:

ķermenis {
                    fona krāsa: #fff;
}

npm palaist lint:scss

Jums konsoles logā vajadzētu redzēt kaut ko līdzīgu šim:

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

assets/scss/styles.scss

2:21 ✖ Sagaidāmais 2 atstarpju ievilkums ievilkums

1 pārbaudīts avots

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

Atrasta 1 problēma

nopietnības līmenis "kļūda": 1

ievilkums: 1

npm ERR! kods ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Iziešanas statuss 2

Tas faktiski nozīmē, ka mūsu linteris darbojas!

Rezultātā ir precīzi parādīts, kurā rindā ir kļūda, un aprakstīta problēma, kas jāatrisina. Dažas problēmas nav novēršamas automātiski, jo tām ir nepieciešams izstrādātāja lēmums, bet vairumā gadījumu jums vienkārši ir jāizpilda tā pati komanda ar -fix iespēja, tāpēc palaidīsim to.

npm palaist lint:scss:fix

Tagad jums vajadzētu redzēt zaļu izvades signālu bez atrastām kļūdām:

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


1 pārbaudīts avots

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

Atrasts 0 problēmu

4. ESLint pievienošana

Šis solis ir gandrīz tāds pats kā iepriekšējais. Mēs instalēsim ESLint, definēsim noklusējuma noteikumu kopumu un deklarēsim divus NPM skriptus - vienu CI, otru - iepriekšējai izspiešanai. Pārejam cauri šim!

Ja ikdienas darbā izmantojat NPM, iespējams, vēlaties instalēt ESLint globāli. Ja tā nav, lūdzu, skatiet instalēšanas norādījumus sadaļā oficiālie dokumenti.

npm install -g eslint

Kad jūsu datorā ir pieejama komanda eslint, vienkārši palaidiet to savā projektā:

eslint --init

Ievērojot tālākās instrukcijas, kas parādās terminālī, vienkārši pieņemiet dažus projekta lēmumus, piemēram:

• Javascript vai TypeScript
• Airbnb vai Google stilā
• konfigurācijas tips (JSON fails, JS fails vai inline in package.json)
• ES moduļi (imports/eksports) vai pieprasīt sintakse

Šajā vietā ir vērts uzrakstīt dažus vārdus par koda formatētāju ar nosaukumu Prettier. Tas ir pilnībā standartizēts un saderīgs ar lielāko daļu koda redaktoru (piemēram, VS Code). Prettier nodrošina daudzus iepriekš definētu koda stilizēšanas noteikumu kopumus, sadarbojas ar linteriem un var būt lielisks palīgs, lai panāktu augstāko koda kvalitāti. Lai saprastu, kas īsti ir Prettier, apmeklējiet šo salīdzinājums no oficiālajiem dokumentiem.

Ja tas ir izdarīts, ESlint konfigurācijas fails (piem. .eslintrc.json, (atkarībā no tā, ko esat izvēlējies iepriekš) vajadzētu parādīties jūsu saknes direktorijā, kaut kur blakus .stylelintrc.json izveidots pirms tam.

Tagad mums ir jādefinē skripti package.json failu, tāpat kā SCSS failiem:

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

Apsveicam! ESLint ir gatavs lietošanai jau tagad. Pārbaudīsim, vai tas darbojas pareizi. Izveidot /src/index.js failu ar noteiktu saturu:

console.log("kaut kas");

Palaist linteri:

npm palaist lint:js


Izvades rezultātam vajadzētu izskatīties šādi:

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

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

1:1 brīdinājums Negaidīts konsoles paziņojums no-console

✖ 1 problēma (0 kļūdu, 1 brīdinājums)

Šis brīdinājums nepazudīs pēc -fix iespēja, jo linteri neietekmē potenciāli nozīmīgu kodu. Tie ir paredzēti tikai koda stilizācijai, tostarp baltās atstarpes, jaunās rindkopas, semikoloni, pēdiņas u. c.

5. GitHub darba plūsmu definēšana

GitHub darbplūsmas ir diezgan labi dokumentēta lieta. Jūtieties brīvi, lai iedziļinātos šajā jautājumā, bet pagaidām es ieviesīšu vienkāršu darbplūsmu, lai mūsu kodu pēc ievietošanas attālinātajā repozitorijā (protams, izvietotā GitHub vietnē) atšifrētu.

Izveidot /.github/workflows direktoriju un jaunu code-quality-workflow.yml failu, jo GitHub darbplūsmas ir jādefinē ar YAML failiem.

Lai pareizi darbinātu darbplūsmu, mums ir jāatbild uz dažiem jautājumiem:

• Kad mēs vēlamies palaist mūsu darbplūsmu (pie push, pie pull pieprasījuma, pie apvienošanas utt.)?
• Vai mēs vēlamies izslēgt dažas situācijas (piemēram, push to branch master)?
• Kāda vide mums ir jāiestata, lai pareizi palaistu mūsu komandas (šajā piemērā - Node)?
• Vai mums ir jāinstalē atkarības? Ja jā, tad kā mums to vajadzētu ievietot kešatmiņā?
• Kādi pasākumi mums jāveic, lai pabeigtu pārbaudi?

Pēc dažiem apsvērumiem un dažu stundu darba ar docs piemēru .yml fails var izskatīties šādi:

nosaukums: Kods kvalitāte

on: 'push

darba vietas:
  code-quality:
    nosaukums: Lint source code
    runs-on: ubuntu-latest
    soļi:
    - izmanto: actions/checkout@v1

    - nosaukums: Setup Node
      izmanto: actions/setup-node@v1
      ar:
        nod-version: '12.1'

    - nosaukums: Cache dependencies
      izmanto: actions/cache@v1
      with:
        ceļš: ./node_modules
        atslēga: $((( runner.OS ))-dependencies-$((( hashFiles('**/package-lock.json') ))
        restore-keys: |
          $(( runner.OS ))-atkarības-$(( env.cache-name ))-
          $(( runner.OS ))- atkarības-
          $(( runner.OS ))- $(( runner.OS ))-

    - nosaukums: instalēt atkarības
      palaist: |
        npm install

    - nosaukums: Lint faili
      palaist: |
        npm palaist lint

GitHub nodrošina visu mums nepieciešamo vides saturu. Pēdējā rindā mēs izpildām komandu npm palaist lint kas iepriekš nebija definēts:

"skripti": {
    "lint": "npm run lint:js && npm run lint:scss".
}

Ņemiet vērā, ka mūsu darbplūsmā es neizmantoju :fix komandas.

Kad visas šīs darbības ir paveiktas, varat izbaudīt šo skaisto rezultātu no GitHub pirms Pull pieprasījuma apvienošanas: