Kvalita na prvním místě! 5 snadných kroků k odřádkování kódu pomocí pracovních postupů GitHubu v projektu JavaScript

Co máme dělat, když projekt je malý nebo zákazník stále neví, zda se vyplatí investovat více? Je zřejmé, že na Fáze MVP projektu, kód stylizace nebo unit testy nejsou nejvyšší prioritou. Investoři obvykle chtějí mít dobrý produkt a no tak - když to funguje, tak to nepotřebuje testování, ne?

Vlastně mám nějaké zkušenosti s vytváření aplikací od nuly, a to i bez použití osvědčených postupů. Některé obchodní okolnosti mě donutily hledat kompromis mezi rozpočtovými plány investora a seznamem "nice-to-have" developera. Naštěstí pokud používáte GitHub, většinu běžných problémů souvisejících s kvalitou kódu lze vyřešit během několika minut.

V tomto článku vám ukážu, jak používat pracovní postupy GitHub v prostředí Node.js ke standardizaci vaší kódové základny.

Než začneme, několik předpokladů:

• Znáte NPM a linuxovou konzoli.
• Máte nějaké zkušenosti s preprocesory stylů, načítacími moduly, bundlery atd.
• Víte, k čemu slouží lintery, a opravdu je chcete použít ve svých projektech.

1. Typická struktura projektu JavaScript

Pokud jste někdy používali nějaké JS frameworky, jako např. Vue nebo React, můžete si snadno všimnout některých společných rysů, např.:

• /src adresář se všemi logickými prvky JS a komponentami,
• /test adresář pro jednotkové a e2e testy,
• /aktiva adresář pro styly, obrázky atd.

I když mluvíme o JavaScript pracujeme v Uzel prostředí, takže je zřejmé, že by tam měly být i některé věci z Node, jako např. package.json, package-lock.json a /node_modules v našem kořenovém adresáři.

Všechny tyto věci jsou na svém místě - to je to, co nazýváme sjezd. Rámce jsou vymyšleny tak, aby poskytovaly určité rozumné konvence, takže se obvykle ani nemusíme starat o počáteční návrhový vzor. Vzhledem k tomu, že v tomto příkladu chci vysvětlit některé přístupy, nebudu aplikovat žádné hotové řešení jako Vue CLI.

Je čas pochopit, co se skrývá pod všemi těmi kouzelnými skripty!

2. Rozšíření typického projektu Node

Abychom mohli poskytovat vysoce kvalitní řešení, měli bychom při vytváření nového projektu začít především s lintery. Zaměřme se na dva lintery - Stylelint pro styly (*.scss) a ESLint pro zdrojové soubory (*.js). Oba tyto lintery jsou k dispozici v NPM a lze je snadno nakonfigurovat. Použití linterů vyžaduje projít procesem instalace, přidat konfigurační soubory a definovat skripty projektu. Udělejme to krok za krokem.

3. Přidání aplikace Stylelint

Instalace aplikace Stylelint v prostředí Node je opravdu jednoduchá. Podle oficiální dokumenty, stačí jen běžet:

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

a počkejte, až bude hotovo.

stylelint-config-standard poskytuje výchozí sadu lintovacích pravidel a lze ji nahradit jakýmkoli balíčkem, který lépe vyhovuje vašim potřebám (např. Airbnb styl). Pak vytvořte nový skrytý soubor .stylelintrc.json, což je konfigurační soubor Stylelintu, který je zodpovědný za načítání našich předdefinovaných pravidel:

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

V tuto chvíli nám chybí pouze nějaký skript NPM (nebo skripty) deklarovaný v souboru package.json, aby bylo možné začít lintovat naše soubory. SCSS soubory. Zde je můj návrh:

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

Jak vidíte, deklaroval jsem skript obsahující -fix - tuto možnost je třeba použít před odesláním změn do úložiště.

Nezapomeňte, že je špatným zvykem používat -fix v toku CI, protože pak kód, který předáváte do produkce, není v úložišti správně stylizován. Proto potřebujeme oba skripty.

Otestujme náš linter vytvořením souboru /assets/scss/styles.scss s určitým obsahem, jako například:

tělo {
                    background-color: #fff;
}

npm run lint:scss

V konzoli byste měli vidět něco takového:

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

assets/scss/styles.scss

2:21 ✖ Očekávané odsazení 2 mezery odsazení

1 zkontrolovaný zdroj

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

Nalezen 1 problém

úroveň závažnosti "error": 1

odsazení: 1

npm ERR! kód ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Exit status 2

To vlastně znamená, že náš linter funguje!

Výstup přesně ukazuje, který řádek způsobuje chybu, a popisuje problém, který je třeba vyřešit. Některé problémy nelze opravit automaticky, protože je k tomu třeba rozhodnutí vývojáře, ale ve většině případů stačí spustit stejný příkaz s příkazem -fix tak ji spusťme.

npm run lint:scss:fix

Nyní by se měl zobrazit zelený výstup bez nalezených chyb:

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


1 zkontrolovaný zdroj

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

Nalezeno 0 problémů

4. Přidání ESLint

Tento krok je téměř stejný jako předchozí. Nainstalujeme ESLint, definujeme výchozí sadu pravidel a deklarujeme dva volatelné skripty NPM - jeden pro CI, druhý pro pre-push. Pojďme si to projít!

Pokud používáte NPM při své každodenní práci, možná byste chtěli nainstalovat ESLint globálně. Pokud ne, podívejte se na návod k instalaci v části oficiální dokumenty.

npm install -g eslint

Pokud je na vašem počítači k dispozici příkaz eslint, stačí jej spustit ve vašem projektu:

eslint --init

Podle dalších pokynů zobrazených v terminálu stačí provést několik rozhodnutí o projektu, jako např.:

• Javascript nebo TypeScript
• Ve stylu Airbnb nebo Google
• typ konfigurace (soubor JSON, soubor JS nebo inline v souboru package.json)
• moduly ES (import/export) nebo vyžadují syntaxe

Na tomto místě stojí za to napsat pár slov o formátovači kódu s názvem Prettier. Je plně standardizovaný a kompatibilní s většinou editorů kódu (např. VS Code). Prettier poskytuje mnoho sad předdefinovaných pravidel pro stylování kódu, spolupracuje s lintery a může být skvělou podporou při honbě za špičkovou kvalitou kódu. Chcete-li pochopit, co přesně Prettier je, navštivte tuto stránku porovnání z oficiálních dokumentů.

Pokud je to provedeno, konfigurační soubor ESlint (např. .eslintrc.json(v závislosti na tom, co jste zvolili dříve) by se měl objevit v kořenovém adresáři, někde vedle adresáře .stylelintrc.json vytvořené předtím.

Nyní musíme definovat skripty v package.json stejně jako u souborů SCSS:

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

Gratulujeme! ESLint je připraven k použití. Zkontrolujme, zda funguje správně. Vytvořte stránku /src/index.js soubor s určitým obsahem:

console.log("něco");

Spusťte linter:

npm run lint:js


Výstup by měl vypadat takto:

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

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

1:1 warning Neočekávaný konzolový příkaz no-console

✖ 1 problém (0 chyb, 1 varování)

Toto upozornění nezmizí ani po použití -fix možnost, protože linters neovlivňuje potenciálně smysluplný kód. Jsou určeny pouze pro stylizaci kódu, včetně bílých mezer, nových řádků, středníků, uvozovek atd.

5. Definování pracovních postupů GitHubu

Pracovní postupy GitHub jsou poměrně dobře zdokumentované. Klidně se do toho ponořte hlouběji, ale zatím budu implementovat jednoduchý pracovní postup pro lintování našeho kódu po odeslání do vzdáleného repozitáře (samozřejmě hostovaného na GitHubu).

Vytvořit /.github/workflows adresář a nový code-quality-workflow.yml protože pracovní postupy GitHubu musí být definovány pomocí souborů YAML.

Abychom mohli spustit správný pracovní postup, musíme si zodpovědět několik otázek:

• Kdy chceme spustit náš pracovní postup (při odeslání, při požadavku na stažení, při sloučení atd.)?
• Chceme vyloučit některé situace (například odeslání do větve master)?
• Jaké prostředí musíme nastavit, abychom mohli správně spouštět naše příkazy (v tomto příkladu - Node)?
• Musíme nainstalovat závislosti? Pokud ano, jak je máme uložit do mezipaměti?
• Jaké kroky musíme provést, abychom kontrolu dokončili?

Po několika úvahách a několika hodinách práce s příkladem dokumentace .yml může vypadat takto:

název: Kód kvality

on: "push

jobs:
  code-quality:
    name: Lint zdrojový kód
    runs-on: ubuntu-latest
    steps:
    - používá: actions/checkout@v1

    - název: Setup Node
      uses: actions/setup-node@v1
      with:
        node-version: '12.1'

    - name: Cache dependencies
      uses: actions/cache@v1
      with:
        Cesta: ./node_modules
        key: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        restore-keys: |
          $(( runner.OS ))-závislosti-$(( env.cache-name ))-
          $(( runner.OS ))-dependencies-
          $(( runner.OS ))-

    - název: Instalace závislostí
      run: |
        npm install

    - název: Lint soubory
      run: |
        npm run lint

GitHub poskytuje všechny potřebné informace o životním prostředí. V posledním řádku spouštíme příkaz npm run lint který nebyl dříve definován:

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

Všimněte si, že v našem pracovním postupu nepoužívám :fix příkazy.

Po dokončení všech těchto kroků se můžete těšit na tento krásný výstup z GitHubu před sloučením žádosti o stažení: