Kvalitet först! 5 enkla steg för att linta din kod med GitHub-arbetsflöden i JavaScript-projektet

Vad ska vi göra när projekt är liten eller om kunden fortfarande inte vet om det är värt att investera mer? Uppenbarligen är det vid MVP-fasen av projektet, kod styling eller enhetstester är inte högsta prioritet. Investerare vill vanligtvis ha en bra Produkt och kom igen - om det fungerar behöver det inte testas, eller hur?

Jag har faktiskt en del erfarenhet av bygga appar från grundenäven utan att använda bästa praxis i första hand. Vissa affärsomständigheter tvingade mig att leta efter kompromissen mellan en investerares budgetplaner och utvecklarens "nice-to-have"-lista. Tack och lov, om du använder GitHub, kan de flesta av de vanliga problemen relaterade till kodkvalitet lösas på några minuter.

I den här artikeln ska jag visa dig hur du använder GitHub-arbetsflöden i Node.js-miljön för att standardisera din kodbas.

Några antaganden innan vi börjar:

• Du är bekant med NPM och Linux-konsolen.
• Du har viss erfarenhet av stilpreprocessorer, modulladdare, bundlers etc.
• Du vet vad linters är till för och vill verkligen använda dem i dina projekt.

1. Typisk projektstruktur för JavaScript

If you ever used some JS frameworks like Vue or React, you can easily spot some common things between them, e.g.:

• /source med all din JS-logik och alla dina komponenter,
• /test katalog för enhets- och e2e-test,
• /tillgångar katalog för stilar, bilder etc.

Även om vi talar om JavaScript projekt arbetar vi i Nod miljö, så självklart bör det också finnas några Node-grejer som paket.json, paket-lås.json och /node_moduler katalogen i vår rotkatalog.

Alla dessa saker är på sin plats - det är vad vi kallar Konvention. Ramverk är uppfunna för att tillhandahålla några rimliga konventioner, så vanligtvis behöver vi inte ens bry oss om det ursprungliga designmönstret. Som i det här exemplet vill jag förklara några tillvägagångssätt, jag kommer inte att tillämpa några färdiga lösningar som Vue CLI.

Dags att förstå vad som döljer sig bakom alla dessa magiska lint-skript!

2. Utökning av det typiska Node-projektet

För att tillhandahålla högkvalitativa lösningar är linters det första vi bör börja med när vi skapar ett nytt projekt. Låt oss fokusera på två linters - Stylelint för stilar (*.scss) och ESLint för källfiler (*.js). Båda dessa linters finns tillgängliga på NPM och är ganska enkla att konfigurera. Att använda linters kräver att man går igenom installationsprocessen, lägger till konfigurationsfiler och definierar projektskript. Låt oss göra det steg för steg.

3. Lägga till Stylelint

Installationen av Stylelint i Node-miljön är väldigt enkel. Enligt officiella dokumentbehöver du bara springa:

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

och vänta tills det är klart.

stylelint-konfiguration-standard innehåller en standarduppsättning av linting-regler och kan ersättas med valfritt paket som passar dina behov bättre (t.ex. Airbnb-stil). Skapa sedan en ny dold fil .stylelintrc.jsonsom är Stylelints konfigurationsfil och som ansvarar för att ladda våra fördefinierade regler:

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

Just nu är det enda som saknas något NPM-skript (eller skript) som deklareras i filen package.json för att börja linting våra SCSS-filer. Här är mitt förslag:

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

Som du kan se har jag deklarerat skriptet som innehåller -fix alternativet - det här alternativet ska användas innan ändringar läggs till i förvaret.

Kom ihåg - det är en dålig idé att använda -fix i ditt CI-flöde, eftersom koden som du skickar till produktionen då inte stylas korrekt i repositoryt. Det är därför vi behöver båda skripten.

Låt oss testa vår linter genom att skapa en fil /tillgångar/scss/styles.scss med lite innehåll, typ:

kropp {
                    bakgrundsfärg: #fff;
}

npm kör lint:scss

Du bör se något liknande i din konsol:

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

tillgångar/scss/styles.scss

2:21 ✖ Förväntad indragning av 2 mellanslag indragning

1 källa kontrollerad

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

1 problem hittades

allvarlighetsgrad nivå "fel": 1

indragning: 1

npm ERR! kod ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Avsluta status 2

Detta betyder faktiskt att vår linter fungerar!

Utdata visar exakt vilken rad som orsakar ett fel och beskriver det problem som ska lösas. Vissa problem kan inte åtgärdas automatiskt eftersom de kräver ett beslut av en utvecklare, men i de flesta fall behöver du bara köra samma kommando med -fix alternativet, så låt oss köra det.

npm kör lint:scss:fix

Nu bör du se ett grönt utdata med inga fel hittade:

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


1 källa kontrollerad

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

0 problem hittades

4. Lägga till ESLint

Detta steg är nästan detsamma som det föregående. Vi kommer att installera ESLint, definiera några standardregler och deklarera två anropsbara NPM-skript - ett för CI, ett för pre-push. Låt oss gå igenom detta!

Om du använder NPM i ditt dagliga arbete kanske du vill installera ESLint globalt. Om du inte gör det, vänligen kontrollera installationsinstruktionerna i officiella dokument.

npm installera -g eslint

När kommandot eslint finns tillgängligt på din maskin är det bara att köra det i ditt projekt:

eslint --init

Följ ytterligare instruktioner som visas i din terminal och fatta bara några projektbeslut som:

• Javascript eller TypeScript
• Airbnb-stil eller Google-stil
• konfigurationstyp (JSON-fil, JS-fil eller inline i paket.json)
• ES-moduler (import/export) eller kräva syntax

På den här platsen är det värt att skriva ett ord om kodformaterare som heter Prettier. Den är helt standardiserad och kompatibel med de flesta kodredigerare (t.ex. VS Code). Prettier tillhandahåller många uppsättningar fördefinierade kodstylingregler, samarbetar med linters och kan vara ett bra stöd för att jaga högsta kvalitet på koden. För att förstå vad exakt Prettier är, besök detta jämförelse från officiella dokument.

Om det är gjort kommer ESlints konfigurationsfil (t.ex. .eslintrc.json(beroende på vad du har valt tidigare) bör visas i din rotkatalog, någonstans bredvid .stylelintrc.json skapade tidigare.

Nu måste vi definiera skript i paket.json fil, på samma sätt som för SCSS-filer:

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

Gratulerar, grattis! ESLint är redo att användas just nu. Låt oss kontrollera att det fungerar korrekt. Skapa /src/index.js fil med visst innehåll:

console.log("något");

Kör linter:

npm kör lint:js


Utmatningen bör se ut så här:

> eslint '**/*.js' --ignore-mönster node_modules/

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

1:1 warning Oväntat konsoluttalande no-console

✖ 1 problem (0 fel, 1 varning)

Denna varning försvinner inte efter användning -fix alternativ, eftersom linters påverkar inte potentiellt meningsfull kod. De är bara till för kodstyling, inklusive vita mellanrum, nya linjer, semikolon, citattecken etc.

5. Definiera arbetsflöden för GitHub

Arbetsflöden i GitHub är en ganska väldokumenterad sak. Du får gärna gräva djupare i detta, men för tillfället ska jag implementera ett enkelt arbetsflöde för att linta vår kod efter push till fjärrförvaret (uppenbarligen värd på GitHub).

Skapa /.github/arbetsflöden katalog och ny kod-kvalitet-arbetsflöde.yml filen där eftersom GitHub-arbetsflöden måste definieras med YAML-filer.

För att kunna köra ett korrekt arbetsflöde måste vi svara på några frågor:

• När vill vi köra vårt arbetsflöde (på push, på pull request, på merge etc.)?
• Vill vi utesluta vissa situationer (t.ex. push till branch master)?
• Vilken miljö behöver vi konfigurera för att köra våra kommandon korrekt (i det här exemplet - Node)?
• Behöver vi installera beroenden? Om så är fallet, hur ska vi cacha det?
• Vilka åtgärder behöver vi vidta för att slutföra kontrollen?

Efter några överväganden och några timmars arbete med dokument exempel .yml filen kan se ut så här:

namn: Kodkvalitet

på: "push

jobb
  kod-kvalitet:
    namn: Lint källkod
    körs på: ubuntu-latest
    steg:
    - använder: actions/checkout@v1

    - namn: Konfigurera nod
      använder: actions/setup-node@v1
      med:
        node-version: '12.1'

    - namn: Cache-beroenden
      använder: actions/cache@v1
      med:
        sökväg: ./node_modules
        key: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        återställa nycklar: |
          $(( runner.OS ))-beroenden-$(( env.cache-name ))-
          $(( runner.OS ))-beroenden-
          $(( runner.OS ))-

    - name: Installera beroenden
      kör: |
        npm installera

    - namn: Lint-filer
      kör: |
        npm kör lint

GitHub tillhandahåller alla miljögrejer vi behöver. I den sista raden kör vi kommandot npm kör lint som inte var definierad tidigare:

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

Observera att jag i vårt arbetsflöde inte använder :fix kommandon.

När alla dessa steg är klara kan du njuta av denna vackra utdata från GitHub innan du sammanfogar din Pull Request: