VS Code pour WordPress : extensions, EditorConfig et réglages d’équipe

Sur un projet à quatre développeurs, chaque revue de code faisait remonter les mêmes remarques : tabulations contre espaces, guillemets simples contre doubles, ligne finale manquante. Rien de grave individuellement, mais cumulé, cela polluait chaque pull request et détournait l’attention des vrais problèmes. La solution n’est pas une charte de bonnes intentions, mais une configuration d’éditeur versionnée que chacun récupère automatiquement en clonant le dépôt.

Cette recette couvre l’autocomplétion WordPress dans VS Code, l’intégration de PHPCS et la configuration EditorConfig. Le débogage avec Xdebug fait l’objet d’un autre article.

Intelephense et les stubs WordPress

L’extension Intelephense (bmewburn.vscode-intelephense-client) offre une autocomplétion PHP bien plus fiable que l’extension PHP officielle par défaut. Par défaut, elle ne connaît rien des fonctions WordPress comme get_the_title() ou register_post_type() — il faut lui fournir les stubs, c’est-à-dire des déclarations de fonctions sans implémentation, générées à partir du code source de WordPress.

Dans les réglages du projet (.vscode/settings.json) :

{
  "intelephense.environment.includePaths": [
    "vendor/php-stubs/wordpress-stubs"
  ],
  "intelephense.files.exclude": [
    "**/.git/**",
    "**/node_modules/**",
    "**/vendor/**/tests/**"
  ]
}

Le paquet php-stubs/wordpress-stubs s’installe via Composer, en dépendance de développement uniquement :

composer require --dev php-stubs/wordpress-stubs

Avec ces stubs en place, l’autocomplétion propose les vraies signatures de fonctions WordPress, y compris leurs types de retour et la documentation associée, directement au survol.

PHPCS intégré à l’éditeur

L’extension phpcs (persoderman.vscode-phpcs, ou plus récente shevaua.phpcs) affiche les violations de style directement dans l’éditeur, soulignées comme des erreurs classiques. Elle nécessite un phpcs.xml à la racine du projet, référençant le standard WordPress Coding Standards :

<?xml version="1.0"?>
<ruleset name="Projet">
  <rule ref="WordPress"/>
  <config name="testVersion" value="8.0-"/>
  <exclude-pattern>*/vendor/*</exclude-pattern>
</ruleset>

Et l’installation des standards via Composer :

composer require --dev wp-coding-standards/wpcs squizlabs/php_codesniffer

Un développeur voit désormais l’erreur au moment même où il l’écrit, plutôt qu’après un git push rejeté par le hook de pré-commit ou par la CI.

EditorConfig pour l’indentation et les fins de ligne

EditorConfig règle un problème plus élémentaire mais tout aussi source de frictions : l’indentation et les fins de ligne. VS Code lit nativement un fichier .editorconfig à la racine (l’extension EditorConfig for VS Code renforce ce comportement sur les anciennes versions) :

root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.{js,json,yml,yaml}]
indent_size = 2

La coexistence de plusieurs standards d’indentation dans un même projet WordPress est fréquente : PHP en quatre espaces suivant les WPCS, JavaScript et JSON en deux espaces suivant les conventions du bloc éditeur. EditorConfig gère cette distinction par extension sans configuration supplémentaire côté éditeur individuel.

Snippets partagés pour l’équipe

Un fichier de snippets versionné dans .vscode/php.code-snippets permet de standardiser les structures répétitives, comme l’enregistrement d’un type de contenu personnalisé :

{
  "Custom Post Type": {
    "prefix": "wpcpt",
    "body": [
      "register_post_type( '${1:cpt_slug}', array(",
      "    'labels' => array( 'name' => __( '${2:Nom}', 'textdomain' ) ),",
      "    'public' => true,",
      "    'show_in_rest' => true,",
      "    'supports' => array( 'title', 'editor', 'thumbnail' ),",
      ") );"
    ]
  }
}

Tout membre de l’équipe qui tape wpcpt puis Tab récupère instantanément une structure conforme aux conventions du projet, sans avoir à se souvenir de chaque argument.

Fichiers de configuration à versionner

• .editorconfig à la racine, pour l’indentation et les fins de ligne
• .vscode/settings.json, pour les réglages Intelephense et PHPCS spécifiques au projet
• .vscode/extensions.json, qui recommande automatiquement les extensions nécessaires à l’ouverture du dossier
• phpcs.xml, pour le standard de code appliqué

Le fichier .vscode/extensions.json mérite une attention particulière : VS Code propose automatiquement d’installer les extensions listées dès qu’un nouveau développeur ouvre le projet, ce qui réduit considérablement le temps d’onboarding.

Notre verdict

Une configuration d’équipe versionnée ne remplace pas une revue de code attentive, mais elle en supprime le bruit : plus de débat sur la largeur d’une tabulation, plus d’alerte tardive en CI sur une convention de nommage. Le temps investi à mettre en place ces quatre fichiers se rembourse dès la deuxième pull request du projet.