La qualité avant tout ! 5 étapes faciles pour lester votre code avec les workflows GitHub dans le projet JavaScript

Que devons-nous faire lorsque le projet est faible ou que le client ne sait pas encore s'il vaut la peine d'investir davantage ? Il est évident qu'au Phase MVP du projet, code Les tests de style ou les tests unitaires ne sont pas la priorité absolue. Les investisseurs souhaitent généralement disposer d'un bon produit Et puis, si ça marche, ça n'a pas besoin d'être testé, n'est-ce pas ?

En fait, j'ai une certaine expérience en matière de créer des applications à partir de zéroMême sans utiliser les meilleures pratiques en premier lieu. Certaines circonstances commerciales m'ont obligé à chercher un compromis entre les plans budgétaires d'un investisseur et la liste des "choses à faire" d'un développeur. Heureusement, si vous utilisez GitHub, la plupart des problèmes courants liés à la qualité du code peuvent être résolus en quelques minutes.

Dans cet article, je vais vous montrer comment utiliser les workflows GitHub dans l'environnement Node.js pour standardiser votre base de code.

Quelques hypothèses avant de commencer :

• Vous êtes familier avec NPM et la console Linux.
• Vous avez une certaine expérience des préprocesseurs de style, des chargeurs de modules, des bundlers, etc.
• Vous savez à quoi servent les linters et vous voulez vraiment les utiliser dans vos projets.

1. Structure typique d'un projet JavaScript

Si vous avez déjà utilisé des frameworks JS comme Vue ou React, vous pouvez facilement repérer certains points communs entre eux, par exemple :

• /src avec toute la logique et les composants JS,
• /test pour les tests unitaires et les tests e2e,
• /actifs pour les styles, les images, etc.

Même s'il s'agit de JavaScript projet, nous travaillons en Nœud Il est donc évident qu'il doit y avoir aussi des éléments Node comme package.json, package-lock.json et /node_modules dans notre répertoire racine.

Toutes ces choses sont à leur place - c'est ce que nous appelons la convention. Les frameworks sont inventés pour fournir des conventions raisonnables, de sorte qu'habituellement, nous n'avons même pas besoin de nous soucier du modèle de conception initial. Comme dans cet exemple, je veux expliquer quelques approches, je n'appliquerai pas de solutions prêtes à l'emploi comme Vue CLI.

Il est temps de comprendre ce qui se cache sous tous ces scripts de charpie magiques !

2. Extension du projet Node typique

Pour fournir des solutions de haute qualité, les linters sont la première chose avec laquelle nous devrions commencer lors de la création d'un nouveau projet. Nous allons nous concentrer sur deux linters - Stylelint pour les styles (*.scss) et ESLint pour les fichiers sources (*.js). Ces deux linters sont disponibles sur NPM et assez faciles à configurer. L'utilisation des linters nécessite de passer par le processus d'installation, d'ajouter des fichiers de configuration et de définir des scripts de projet. Nous allons le faire étape par étape.

3. Ajout de Stylelint

L'installation de Stylelint dans l'environnement Node est très simple. D'après documents officielsIl suffit de courir :

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

et attendez qu'il soit terminé.

stylelint-config-standard fournit un ensemble de règles d'analyse par défaut et peut être remplacé par n'importe quel paquetage qui répond mieux à vos besoins (par ex. Le style Airbnb). Créez ensuite un nouveau fichier caché .stylelintrc.jsonqui est le fichier de configuration de Stylelint, responsable du chargement de nos règles prédéfinies :

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

Pour l'instant, la seule chose qui manque est un script NPM (ou des scripts) déclaré dans le fichier package.json pour commencer à lier nos fichiers SCSS. Voici ma proposition :

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

Comme vous pouvez le voir, j'ai déclaré le script contenant -fixe Cette option doit être utilisée avant de transférer les modifications dans le référentiel.

N'oubliez pas que c'est une mauvaise pratique que d'utiliser -fixe dans votre flux de CI, car alors le code que vous transmettez à la production n'est pas stylé correctement dans le référentiel. C'est pourquoi nous avons besoin des deux scripts.

Testons notre linter en créant un fichier /assets/scss/styles.scss avec un certain contenu, comme :

body {
                    couleur de fond : #fff ;
}

npm run lint:scss

Vous devriez voir dans votre console quelque chose comme ceci :

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

assets/scss/styles.scss

2:21 ✖ Indentation attendue de 2 espaces indentation

1 source vérifiée

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

1 problème trouvé

niveau de gravité "error" : 1

indentation : 1

npm ERR ! code ELIFECYCLE

npm ERR ! errno 2

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

npm ERR ! Exit status 2

Cela signifie en fait que notre linter fonctionne !

La sortie indique exactement la ligne qui provoque une erreur et décrit le problème à résoudre. Certains problèmes ne peuvent pas être résolus automatiquement car ils nécessitent la décision d'un développeur, mais dans la majorité des cas, il suffit d'exécuter la même commande avec l'option -fixe et nous allons donc l'exécuter.

npm run lint:scss:fix

Vous devriez maintenant voir une sortie verte sans erreur trouvée :

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


1 source vérifiée

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

0 problèmes trouvés

4. Ajout d'ESLint

Cette étape est presque la même que la précédente. Nous allons installer ESLint, définir quelques règles par défaut et déclarer deux scripts NPM appelables - un pour le CI, un pour le pre-push. C'est parti !

Si vous utilisez NPM dans votre travail quotidien, peut-être aimeriez-vous installer ESLint globalement. Si ce n'est pas le cas, veuillez consulter les instructions d'installation dans documents officiels.

npm install -g eslint

Lorsque la commande eslint est disponible sur votre machine, exécutez-la dans votre projet :

eslint --init

En suivant les instructions affichées dans votre terminal, il suffit de prendre quelques décisions concernant le projet, comme par exemple :

• Javascript ou TypeScript
• À la manière d'Airbnb ou de Google
• type de configuration (fichier JSON, fichier JS ou en ligne dans package.json)
• Modules ES (importation/exportation) ou exiger syntaxe

Il convient ici de parler du formateur de code Prettier. Il est entièrement standardisé et compatible avec la plupart des éditeurs de code (par exemple VS Code). Prettier fournit de nombreux ensembles de règles de style de code prédéfinies, travaille avec les linters et peut être d'un grand soutien dans la recherche de la meilleure qualité de code. Pour comprendre ce qu'est exactement Prettier, visitez le site suivant comparaison à partir des documents officiels.

Si c'est le cas, le fichier de configuration d'ESlint (par ex. .eslintrc.jsonen fonction de ce que vous avez choisi auparavant) devrait apparaître dans votre répertoire racine, quelque part à côté de .stylelintrc.json créé auparavant.

Nous devons maintenant définir des scripts dans package.json comme pour les fichiers SCSS :

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

Félicitations ! ESLint est prêt à être utilisé. Vérifions s'il fonctionne correctement. Créer /src/index.js avec un certain contenu :

console.log("quelque chose") ;

Liner de course :

npm run lint:js


Le résultat devrait ressembler à ceci :

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

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

1:1 avertissement Déclaration de console inattendue no-console

✖ 1 problème (0 erreur, 1 avertissement)

Cet avertissement ne disparaît pas après l'utilisation de -fixe car l'option Les linters n'affectent pas le code potentiellement significatif. Ils ne servent qu'à styliser le codey compris les espaces blancs, les nouvelles lignes, les points-virgules, les guillemets, etc.

5. Définir les flux de travail GitHub

Flux de travail GitHub sont assez bien documentés. N'hésitez pas à approfondir la question, mais pour l'instant, je vais mettre en place un flux de travail simple pour lester notre code après l'avoir poussé vers le dépôt distant (évidemment, hébergé sur GitHub).

Créer /.github/workflows et de nouveaux code-quality-workflow.yml car les flux de travail GitHub doivent être définis avec des fichiers YAML.

Pour mettre en place un flux de travail adéquat, nous devons répondre à quelques questions :

• Quand voulons-nous exécuter notre flux de travail (sur push, sur pull request, sur merge etc.) ?
• Voulons-nous exclure certaines situations (comme la poussée vers la branche master) ?
• Quel environnement devons-nous configurer pour exécuter correctement nos commandes (dans cet exemple - Node) ?
• Devons-nous installer des dépendances ? Si oui, comment devons-nous les mettre en cache ?
• Quelles sont les étapes à suivre pour compléter le contrôle ?

Après quelques considérations et quelques heures de travail avec l'exemple de la documentation .yml peut se présenter comme suit :

nom : Qualité du code

on : 'push'

jobs :
  code-quality :
    name : Lint source code
    s'exécute sur : ubuntu-latest
    steps :
    - uses : actions/checkout@v1

    - nom : Setup Node
      utilise : actions/setup-node@v1
      avec :
        node-version : '12.1'

    - name : Dépendances du cache
      utilisations : actions/cache@v1
      avec :
        chemin : ./node_modules
        key : $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        restore-keys : |
          $(( runner.OS ))-dependencies-$(( env.cache-name ))-
          $(( runner.OS ))-dépendances-
          $(( runner.OS ))-dépendances-

    - name : Installer les dépendances
      exécuter : |
        npm install

    - name : Lint files
      run : |
        npm run lint

GitHub fournit tous les éléments environnementaux dont nous avons besoin. Dans la dernière ligne, nous lançons la commande npm run lint qui n'était pas défini auparavant :

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

Notez que dans notre flux de travail, je n'utilise pas de :fix commandes.

Lorsque toutes ces étapes sont terminées, vous pouvez profiter de cette belle sortie de GitHub avant de fusionner votre Pull Request :