# ESLint et Stylelint avec @wordpress/scripts : configurer le lint JS et CSS de vos blocs

> Étendre les configurations officielles fournies par @wordpress/scripts, ajouter des règles maison, intégrer l'éditeur et corriger en masse les fichiers existants.

- Auteur : Clément Hadrot
- Publié le : 2022-08-04
- Mis à jour le : 2022-08-04
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/eslint-stylelint-wordpress-scripts-lint/

## L’essentiel

- Les configurations officielles couvrent déjà l'essentiel
- Étendre plutôt que réécrire depuis zéro
- --fix corrige automatiquement une large part des alertes

Une équipe qui démarrait son premier bloc Gutenberg personnalisé a passé une demi-journée à configurer ESLint à la main, en copiant une configuration trouvée sur un dépôt tiers, avant de découvrir que `@wordpress/scripts` embarquait déjà des configurations ESLint et Stylelint officielles, alignées sur les conventions du cœur et maintenues par l'équipe Gutenberg elle-même. Repartir de ces configurations plutôt que d'en écrire une nouvelle évite des divergences de style avec le reste de l'écosystème des blocs.

`@wordpress/scripts` expose directement les commandes `lint-js` et `lint-style`, déjà câblées sur les configurations officielles `@wordpress/eslint-plugin` et `@wordpress/stylelint-config`.

## Lancer le lint avec les configurations officielles

```
npm install --save-dev @wordpress/scripts

// package.json
{
  "scripts": {
    "lint:js": "wp-scripts lint-js src",
    "lint:css": "wp-scripts lint-style src/**/*.scss"
  }
}
```

```
npm run lint:js
npm run lint:css
```

Sans configuration supplémentaire, ces commandes appliquent déjà les règles recommandées pour les composants React, les hooks, l'accessibilité de base des blocs, et les conventions d'écriture SCSS du cœur.

## Étendre plutôt que remplacer

Pour ajouter des règles propres au projet sans perdre les bénéfices de la configuration officielle, il faut étendre `plugin:@wordpress/eslint-plugin/recommended` plutôt que de repartir d'une configuration vide :

```
// .eslintrc.js
module.exports = {
    extends: [ 'plugin:@wordpress/eslint-plugin/recommended' ],
    rules: {
        'no-console': 'error',
        camelcase: [ 'warn', { properties: 'never' } ],
    },
};
```

> L'essentiel à retenir : Les configurations officielles couvrent déjà l'essentiel ; Étendre plutôt que réécrire depuis zéro ; --fix corrige automatiquement une large part des alertes

```
// .stylelintrc.js
module.exports = {
    extends: [ '@wordpress/stylelint-config' ],
    rules: {
        'selector-class-pattern': null,
    },
};
```

## Intégrer le lint à l'éditeur

Le lint en ligne de commande a peu de valeur s'il n'est consulté qu'au moment du commit. Sur VS Code, les extensions ESLint et Stylelint officielles lisent automatiquement ces fichiers de configuration et surlignent les erreurs directement dans l'éditeur, à condition que le paramètre `eslint.workingDirectories` pointe vers la racine du projet quand celui-ci n'est pas à la racine du dépôt.

## Corriger en masse les fichiers existants

Sur un projet legacy jamais linté auparavant, activer ces règles d'un coup génère souvent des centaines d'alertes. L'option `--fix` corrige automatiquement tout ce qui est mécanique — espacement, guillemets, ordre d'import — sans intervention manuelle :

```
wp-scripts lint-js --fix src
wp-scripts lint-style --fix src/**/*.scss
```

- Lancer `--fix` dans un commit dédié, séparé de tout changement fonctionnel
- Traiter ensuite les alertes restantes une par une, celles qui touchent à la logique et non au style
- Envisager un fichier d'exceptions temporaire (`eslint-disable` ciblé) plutôt que de désactiver une règle entière du projet pour un cas isolé

## Ajouter une règle spécifique aux conventions internes

Au-delà des correctifs mécaniques, une équipe finit toujours par vouloir imposer une convention qui lui est propre, par exemple interdire l'usage direct de `fetch()` au profit du wrapper `@wordpress/api-fetch`, qui gère nativement les nonces REST et les erreurs WordPress. ESLint permet d'écrire une règle personnalisée simple avec `no-restricted-imports`, sans avoir à développer un plugin ESLint complet :

```
module.exports = {
    extends: [ 'plugin:@wordpress/eslint-plugin/recommended' ],
    rules: {
        'no-restricted-globals': [ 'error', 'fetch' ],
        'no-restricted-imports': [
            'error',
            {
                paths: [
                    {
                        name: 'axios',
                        message: 'Utilisez @wordpress/api-fetch plutôt qu axios.',
                    },
                ],
            },
        ],
    },
};
```

Ce type de règle, une fois posée, évite qu'une nouvelle recrue réintroduise une dépendance déjà écartée par l'équipe pour une bonne raison, sans qu'il faille le rappeler à chaque revue de code.

## Faire cohabiter le lint avec l'intégration continue

En complément de l'exécution locale, ajouter `lint:js` et `lint:css` comme étapes distinctes du pipeline d'intégration continue permet de bloquer une pull request même si un développeur a contourné le hook local. Contrairement au hook pre-commit, qui doit rester rapide et ne porter que sur les fichiers modifiés, l'étape de CI peut se permettre d'analyser l'intégralité du dépôt à chaque exécution, sans contrainte de temps ressentie par le développeur au moment du commit.

## En résumé

@wordpress/scripts fournit des configurations ESLint et Stylelint déjà pensées pour Gutenberg, qu'il vaut mieux étendre que reconstruire depuis zéro, en ajoutant seulement les règles propres à vos conventions internes. Le lint PHP, avec PHPCS et les WordPress Coding Standards, répond au même besoin de cohérence de style mais s'appuie sur un outillage complètement distinct, propre à l'écosystème PHP.