Aller au contenu

Analyse statique et linting avec ESLint dans GitLab CI

On souhaite garantir une certaine qualité de code. Avec des outils tel que Sonarqube, tu peux avoir des feedback, te procurant des métriques sur d'eventuelles code smell ou bug, valider selon des quality profiles et quality gates, que nous verrons dans le chapitre Quality Gate avec SonarQube 😋

En attendant pour ce chapitre ci, on va s'interesser à l'étape de Lint. Cette opération d'analyse statique de ton code va te permettre de mettre en évidence d'éventuelles erreurs dans ton code par des vérifications rudimentaires.

Tu pourras en plus d'associer cette étape de vérification, une étape de formatage de ton code te permettant d'avoir un code mieux formatté, et donc plus lisible pour les développeurs lorsqu'ils travaillent de façon collaborative afin de garantir et respecter certains standards et best practices.

Exemple avec NodeJS

Il te faudra au préalable effectuer une installation de tes nodes modules.

Verification du code

Installe ton linteur favori. Ici je te propose le plus standard pour du NodeJS, à savoir eslint

Installe le avec npm install --save-dev eslint

Tu peux initialiser eslint toi même, ou de façon automatique via npm init @eslint/config

On ajoute une nouvelle ligne de script dans notre package.json afin d'appeller notre module :

package.json
1
2
3
4
5
{
    "scripts": {
        "lint": "eslint ."
    }
}

Info

Eslint inclut de nombreuses options avec lui. A savoir si tu veux lint un directory particulier, fix les erreurs en même temps, etc. Tu peux ajouter d'avantages npm module afin de linter du code de framework particulier (Ex: React, CommonJS, ESM, etc.).

Évite les styles Airbnb et Google

Ces presets de style, longtemps incontournables, sont à éviter aujourd'hui : eslint-config-airbnb exige ESLint 7 ou 8 alors qu'ESLint est passé en v10, et eslint-config-google est archivé. Pour le formatage, délègue à Prettier, ou utilise @stylistic/eslint-plugin, qui reprend les règles de formatage dépréciées par ESLint.

Côté gitlab on aura :

1
2
3
4
5
6
7
lint:
    stage: lint
    image: node:24-alpine
    needs:
        - install-deps
    script: 
        - npm run lint

Verification des modules

Rajoutons dans le même stage un nouveau job. Ajoutons le en mode informatif, c'est à dire qu'il apparaisse dans notre workflow mais qu'il ne stop pas la pipeline si celui fail, via la property allow_failure.

Une commande npm outdated du package manager peut s'averer utile pour informer le developpeur, de connaître l'état de santé des modules qu'il utilise. Il pourra ainsi avoir une idée de l'ensemble de ses modules, si ils sont à jour ou non.

On ne souhaite pas seulement qu'un développeur développe des features, selon une user story qu'il aurait pris dans son backlog.

Cela permet de rendre le développeur d'avantage impliqué à maintenir les dépendances de son projets, à des fins de sécurité (notion de ShiftLeft & de DevOps), et non pas seulement à se focus à seulement développer sa feature. Le développeur doit prendre d'avantage de responsabilités.

Info

Les notions de user story, backlog ou encore de sprint appartiennent au framework Scrum, une méthodologie Agile


Notons ici une property needs, qui permet à mon job courant de ne s'executer qu'à la suite de install-deps, et si et seulement si celui-ci passe sans erreur.

1
2
3
4
5
6
7
8
npm-outdated:
    stage: lint
    image: node:24-alpine
    allow_failure: true
    needs:
        - install-deps
    script:
        - npm outdated

Pour aller plus loin