ESLint : intégration continue et performance

ESLint en intégration continue

name: Qualité
on:
  push:
    branches: [main]
  pull_request:

jobs:
  qualite:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx eslint . --max-warnings 0
      - run: npx prettier --check .
      - run: npx tsc --noEmit

Élément	Raison
`npm ci`	Versions exactes du fichier de verrouillage
`--max-warnings 0`	Les avertissements font échouer la CI (sinon ils s’accumulent sans fin)
`prettier --check`	Vérifie le formatage sans modifier
`tsc --noEmit`	Types (voir TypeScript)

Voir Gitea Actions : écrire un workflow.

Codes de sortie

Code	Sens
`0`	Aucune erreur (avertissements tolérés sauf `--max-warnings`)
`1`	Au moins une erreur de règle (ou dépassement de `--max-warnings`)
`2`	Erreur de configuration ou d’exécution (fichier de configuration invalide, plugin absent)

Un code 2 signale un problème d’outil, pas de code : lire le message en début de sortie.

Formats de sortie

npx eslint . -f stylish              # lisible (défaut)
npx eslint . -f json -o rapport-eslint.json
npx eslint . -f json | jq '[.[] | .messages[]] | length'     # nombre de problèmes
npx eslint . -f unix                 # une ligne par problème (analysable)
npx eslint . -f html -o rapport-eslint.html

Pour conserver un rapport dans l’intégration continue :

- run: npx eslint . -f json -o rapport-eslint.json
  continue-on-error: true
- uses: actions/upload-artifact@v3
  with:
    name: rapport-eslint
    path: rapport-eslint.json

upload-artifact@v3 : la version 4 n’est pas prise en charge par Gitea (voir Gitea Actions : cache et artefacts).

Cache

npx eslint . --cache --cache-location node_modules/.cache/eslint/

ESLint ne ré-analyse que les fichiers modifiés (ou dont la configuration a changé). Ajouter le dossier du cache à .gitignore (par défaut .eslintcache). En intégration continue, mettre ce dossier en cache pour accélérer les exécutions suivantes :

- uses: actions/cache@v4
  with:
    path: node_modules/.cache/eslint
    key: eslint-${{ hashFiles('package-lock.json', 'eslint.config.js') }}

Mesurer les règles lentes

TIMING=1 npx eslint .

Rule                                    | Time (ms) | Relative
:---------------------------------------|----------:|--------:
@typescript-eslint/no-floating-promises |   812.340 |    31.2%
import/no-cycle                         |   410.115 |    15.7%

Les règles avec informations de types et celles de graphe de dépendances (import/no-cycle) sont les plus coûteuses. Les réserver à l’intégration continue ou à certains dossiers.

Réduire le temps d’analyse

Levier	Effet
`--cache`	Évite de ré-analyser les fichiers inchangés
Ignorer `dist/`, `coverage/`, fichiers générés	Moins de fichiers
Limiter les règles avec types aux dossiers `src/`	Moins de chargement de TypeScript
`projectService: true` plutôt qu’un `project` multiple	Chargement de TypeScript plus économe
Moins de plugins	Chaque plugin ajoute du temps de chargement
`--concurrency=auto`	Analyse en parallèle (option des versions récentes, voir `eslint --help`)
Analyser seulement les fichiers modifiés (pre-commit)	Retour immédiat

npx eslint --concurrency=auto .        # si disponible dans la version installée

Analyser seulement les fichiers modifiés

En intégration continue sur une demande de fusion :

git fetch origin main
fichiers=$(git diff --name-only --diff-filter=ACMR origin/main...HEAD | grep -E '\.(js|jsx|ts|tsx|astro)$' || true)
[ -z "$fichiers" ] || npx eslint $fichiers --max-warnings 0

Plus rapide, mais ne détecte pas un problème introduit dans un autre fichier par un changement (règles de types, imports). Faire l’analyse complète au moins sur la branche principale.

Durcir progressivement

Pour un projet existant :

Commencer avec js.configs.recommended et les règles en 'warn'.
Mesurer : npx eslint . -f json | jq '[.[] | .messages[]] | length'.
Corriger par lots (--fix, puis à la main), un commit par type de correction.
Passer les règles corrigées en 'error' pour empêcher les régressions.
Activer --max-warnings 0 quand le nombre d’avertissements est nul.

Pour tolérer l’existant sans bloquer : la suppression en masse (--suppress-all dans les versions récentes) enregistre les violations actuelles dans un fichier et n’échoue que sur les nouvelles ; vérifier la disponibilité de cette option dans la version installée.

Avec les hooks

pre-commit : eslint --fix sur les fichiers indexés (lint-staged). La CI fait l’analyse complète : le hook peut être contourné, la CI non (voir Husky : hooks et lint-staged et Husky : intégration continue et équipes).

Qualité du code : un bilan

Contrôle	Commande	Quand
Formatage	`prettier --check .`	CI, hook
Analyse	`eslint . --max-warnings 0`	CI, hook (fichiers modifiés)
Types	`tsc --noEmit` / `astro check`	CI, pre-push
Tests	`vitest run` / `node --test`	CI, pre-push
Sécurité des dépendances	`npm audit`	CI, régulièrement

Dépannage

Symptôme	Piste
La CI échoue sur des avertissements	`--max-warnings 0` : les corriger ou assouplir
Code de sortie 2	Erreur de configuration : plugin absent, `eslint.config.js` invalide
La CI est lente	Cache, règles avec types limitées, `TIMING=1` pour trouver les règles lentes
Résultats différents en local et en CI	Versions d’ESLint ou de plugins différentes : `npm ci`, verrouiller
`JavaScript heap out of memory`	Règles avec types sur un très gros projet : `NODE_OPTIONS=--max-old-space-size=4096`, limiter l’analyse
Le cache donne des résultats obsolètes	Supprimer `.eslintcache`, ou le dossier de cache
Fichiers générés signalés	Ajouter à `ignores`