# VS Code pour WordPress : extensions, EditorConfig et réglages d’équipe > Intelephense, PHPCS intégré, EditorConfig et snippets partagés : la configuration d'éditeur qui évite les débats de style à chaque revue de code. - Auteur : Clément Hadrot - Publié le : 2020-08-05 - Mis à jour le : 2020-08-05 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/vscode-wordpress-extensions-editorconfig/ ## L’essentiel - Intelephense avec stubs WordPress pour l'autocomplétion - PHPCS intégré directement dans l'éditeur - EditorConfig pour une config d'équipe versionnée 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'essentiel à retenir : Intelephense avec stubs WordPress pour l'autocomplétion ; PHPCS intégré directement dans l'éditeur ; EditorConfig pour une config d'équipe versionnée 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 : ``` */vendor/* ``` 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.