La qualità prima di tutto! 5 semplici passi per listare il codice con i flussi di lavoro GitHub nel progetto JavaScript

Che cosa dobbiamo fare, quando il progetto è piccolo o il cliente non sa ancora se vale la pena investire di più? Ovviamente, al Fase MVP del progetto, codice I test di stile o di unità non sono la priorità assoluta. Gli investitori di solito vogliono avere una buona prodotto E poi, se funziona, non ha bisogno di essere testato, giusto?

In realtà, ho una certa esperienza in costruire app da zeroanche senza utilizzare le migliori pratiche. Alcune circostanze aziendali mi hanno costretto a cercare un compromesso tra i piani di budget di un investitore e l'elenco di "cose da fare" dello sviluppatore. Fortunatamente, se si utilizza GitHub, la maggior parte dei problemi comuni relativi alla qualità del codice può essere risolta in pochi minuti.

In questo articolo, vi mostrerò come utilizzare i flussi di lavoro di GitHub nell'ambiente Node.js per standardizzare la vostra base di codice.

Alcune ipotesi prima di iniziare:

• Avete familiarità con NPM e con la console Linux.
• Avete un po' di esperienza con preprocessori di stile, caricatori di moduli, bundler, ecc.
• Sapete a cosa servono le linters e volete davvero utilizzarle nei vostri progetti.

1. Struttura tipica del progetto JavaScript

Se si è mai usato qualche framework JS come Vue o React, è possibile individuare facilmente alcuni elementi in comune tra loro, ad es:

• /src con tutti i componenti e la logica JS,
• /prova per i test unitari e e2e,
• /attività per gli stili, le immagini, ecc.

Anche se stiamo parlando di JavaScript progetto, lavoriamo in Nodo quindi ovviamente dovrebbe esserci anche qualche elemento di Node come pacchetto.json, pacchetto-serratura.json e /moduli_nodi nella nostra directory principale.

Tutte queste cose sono al loro posto - questo è ciò che chiamiamo il convenzione. I framework sono stati inventati per fornire alcune convenzioni ragionevoli, quindi di solito non c'è nemmeno bisogno di preoccuparsi del modello di progettazione iniziale. Poiché in questo esempio voglio spiegare alcuni approcci, non applicherò soluzioni pronte all'uso come la Vue CLI.

È ora di capire cosa c'è sotto tutti questi script magici!

2. Estensione del tipico progetto Node

Per fornire soluzioni di alta qualità, i linters sono la prima cosa da cui partire quando si imposta un nuovo progetto. Concentriamoci su due linters: Stylelint per gli stili (*.scss) e ESLint per i file sorgente (*.js). Entrambi questi linters sono disponibili su NPM e sono piuttosto facili da configurare. L'uso dei linters richiede un processo di installazione, l'aggiunta di file di configurazione e la definizione di script di progetto. Procediamo passo dopo passo.

3. Aggiunta di Stylelint

L'installazione di Stylelint nell'ambiente Node è davvero semplice. In base a documenti ufficiali, è sufficiente correre:

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

e aspettare che sia finito.

configurazione-standard di stylelint fornisce un insieme predefinito di regole di linting e può essere sostituito con qualsiasi pacchetto che soddisfi meglio le vostre esigenze (ad es. Stile Airbnb). Quindi creare un nuovo file nascosto .stylelintrc.jsonche è il file di configurazione di Stylelint, responsabile del caricamento delle regole predefinite:

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

Al momento, l'unica cosa che manca è qualche script NPM (o script) dichiarato nel file package.json per avviare il linting dei nostri file SCSS. Ecco la mia proposta:

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

Come si può vedere, ho dichiarato lo script contenente -Correzione da usare prima di inviare le modifiche al repository.

Ricordate: è una cattiva pratica utilizzare -Correzione nel flusso CI, perché in tal caso il codice passato alla produzione non viene stilizzato correttamente nel repository. Ecco perché abbiamo bisogno di entrambi i copioni.

Testiamo il nostro linter creando un file /assets/scss/styles.scss con alcuni contenuti, come:

corpo {
                    colore di sfondo: #fff;
}

npm run lint:scss

Nella console dovrebbe apparire qualcosa di simile a questo:

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

assets/scss/styles.scss

2:21 ✖ Indentazione attesa di 2 spazi indentazione

1 fonte controllata

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

1 problema trovato

livello di gravità "errore": 1

indentazione: 1

npm ERR! codice ELIFECYCLE

npm ERR! errno 2

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

npm ERR! Stato di uscita 2

Questo significa che il nostro linter funziona!

L'output mostra esattamente quale riga causa un errore e descrive il problema da risolvere. Alcuni problemi non sono risolvibili automaticamente perché richiedono la decisione di uno sviluppatore, ma nella maggior parte dei casi è sufficiente eseguire lo stesso comando con -Correzione e quindi eseguiamola.

npm run lint:scss:fix

Ora si dovrebbe vedere un output verde senza errori:

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


1 sorgente controllata

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

0 problemi trovati

4. Aggiunta di ESLint

Questo passo è quasi identico al precedente. Installeremo ESLint, definiremo alcune regole predefinite e dichiareremo due script NPM richiamabili: uno per il CI e uno per il pre-push. Andiamo avanti!

Se utilizzate NPM nel vostro lavoro quotidiano, forse vorreste installare ESLint a livello globale. Se non lo fate, consultate le istruzioni per l'installazione in documenti ufficiali.

npm install -g eslint

Quando il comando eslint è disponibile sulla macchina, basta eseguirlo nel progetto:

eslint --init

Seguendo le istruzioni visualizzate nel terminale, è sufficiente prendere alcune decisioni sul progetto, come ad esempio:

• Javascript o TypeScript
• Stile Airbnb o stile Google
• tipo di configurazione (file JSON, file JS o inline in pacchetto.json)
• Moduli ES (Importazione/esportazione) o richiedere sintassi

In questa sede vale la pena di parlare del formattatore di codice chiamato Prettier. È completamente standardizzato e compatibile con la maggior parte degli editor di codice (ad esempio VS Code). Prettier fornisce molti set di regole predefinite per lo styling del codice, collabora con i linters e può essere di grande aiuto per ottenere la massima qualità del codice. Per capire che cos'è esattamente Prettier, visitate questo sito confronto dai documenti ufficiali.

Se è stato fatto, il file di configurazione di ESlint (ad es. .eslintrc.jsona seconda di quello che avete scelto in precedenza) dovrebbe apparire nella vostra directory principale, da qualche parte accanto a .stylelintrc.json creato in precedenza.

Ora dobbiamo definire gli script in pacchetto.json come per i file SCSS:

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

Congratulazioni! ESLint è pronto all'uso. Verifichiamo se funziona correttamente. Creare /src/index.js con alcuni contenuti:

console.log("qualcosa");

Eseguire l'inserimento di un liner:

npm run lint:js


Il risultato dovrebbe essere simile a questo:

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

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

1:1 avviso Dichiarazione console inattesa no-console

✖ 1 problema (0 errori, 1 avviso)

Questo avviso non scompare dopo aver utilizzato -Correzione perché non influisce sul codice potenzialmente significativo. Servono solo per lo stile del codicecompresi gli spazi bianchi, le linee nuove, i punti e virgola, le virgolette, ecc.

5. Definire i flussi di lavoro di GitHub

Flussi di lavoro GitHub sono una cosa abbastanza ben documentata. Sentitevi liberi di approfondire l'argomento, ma per il momento implementerò un semplice flusso di lavoro per lincare il nostro codice dopo il push al repository remoto (ovviamente, ospitato su GitHub).

Creare /.github/flussi di lavoro e la nuova directory code-quality-workflow.yml perché i flussi di lavoro di GitHub devono essere definiti con file YAML.

Per eseguire un flusso di lavoro corretto, dobbiamo rispondere ad alcune domande:

• Quando vogliamo eseguire il nostro flusso di lavoro (su push, su richiesta di pull, su merge ecc.)?
• Vogliamo escludere alcune situazioni (come il push al ramo master)?
• Quale ambiente dobbiamo configurare per eseguire correttamente i nostri comandi (in questo esempio - Node)?
• È necessario installare le dipendenze? In caso affermativo, come dovremmo memorizzarle nella cache?
• Quali sono i passi da compiere per completare il controllo?

Dopo alcune considerazioni e qualche ora di lavoro con l'esempio di docs .yml Il file può avere il seguente aspetto:

nome: Codice qualità

su: 'push'

lavori:
  code-quality:
    nome: Lint codice sorgente
    viene eseguito su: ubuntu-latest
    passi:
    - usa: actions/checkout@v1

    - nome: impostare il nodo
      usa: actions/setup-node@v1
      con:
        node-version: '12.1'

    - nome: dipendenze della cache
      usa: actions/cache@v1
      con:
        percorso: ./node_modules
        chiave: $(( runner.OS ))-dipendenze-$(( hashFiles('**/package-lock.json') ))
        chiavi di ripristino: |
          $(( runner.OS ))-dipendenze-$(( env.cache-name ))-
          $(( runner.OS ))-dipendenze-
          $(( runner.OS ))-

    - nome: installare le dipendenze
      eseguire: |
        installare npm

    - nome: Lint i file
      eseguire: |
        npm eseguire lint

GitHub fornisce tutto il materiale ambientale di cui abbiamo bisogno. Nell'ultima riga stiamo eseguendo il comando npm run lint che non era stato definito in precedenza:

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

Si noti che nel nostro flusso di lavoro non si utilizza il metodo :fix comandi.

Una volta completati tutti questi passaggi, si può godere di questo bellissimo output da GitHub prima di unire la richiesta di pull: