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' } ],
},
};
// .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
--fixdans 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-disableciblé) 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.
