Avec la stabilisation de l’éditeur de site complet dans WordPress 5.9, l’équipe cœur a continué à pousser @wordpress/env — plus connu sous son alias wp-env — comme environnement de référence pour développer des blocs et des thèmes de blocs. Contrairement à Local ou à une configuration Docker maison, wp-env est directement maintenu par les équipes qui développent Gutenberg, ce qui garantit une bonne cohérence avec les versions de WordPress ciblées par les développeurs de blocs.
On l’a mis en place sur un projet de thème de blocs récent, en remplacement de notre configuration Docker habituelle, pour voir ce qu’il apporte concrètement.
Installation et premier lancement
wp-env s’installe globalement via npm et nécessite Docker installé sur la machine. Aucune configuration Webpack ni fichier YAML complexe : un simple .wp-env.json à la racine du projet suffit.
npm -g install @wordpress/env
wp-env start{
"core": "WordPress/WordPress#5.9",
"plugins": [ "." ],
"themes": [ "./mon-theme-blocs" ],
"port": 8888,
"config": {
"WP_DEBUG": true,
"WP_DEBUG_LOG": true
}
}La ligne "plugins": [ "." ] indique que le dossier courant du projet est lui-même un plugin, monté automatiquement dans l’environnement. C’est la configuration typique pour développer un plugin de blocs indépendamment d’un site complet.
Ce que wp-env fait à votre place
- Télécharge et configure une instance WordPress correspondant exactement à la version demandée, y compris une version spécifique d’une branche du cœur
- Monte automatiquement le dossier du projet comme plugin ou thème actif, sans manipulation supplémentaire
- Fournit un environnement de test séparé, accessible sur un port distinct, pour lancer les tests d’intégration PHPUnit sans polluer l’environnement de développement
- Configure une instance MySQL et phpMyAdmin accessibles immédiatement
wp-env start
wp-env run tests-cli wp core version
wp-env run cli wp plugin listLa commande wp-env run permet d’exécuter n’importe quelle commande, y compris WP-CLI, directement dans le conteneur, sans avoir à retenir de syntaxe Docker spécifique.
Développer un bloc avec wp-env
Le flux de travail typique combine wp-env pour l’environnement WordPress et @wordpress/scripts pour la compilation du bloc lui-même, les deux étant maintenus par la même équipe et donc naturellement compatibles :
npm run start # wp-scripts start, compile le bloc en continu
wp-env start # environnement WordPress avec le bloc montéModifier le code source du bloc déclenche une recompilation automatique côté wp-scripts, immédiatement visible dans l’éditeur ouvert via wp-env, sans étape manuelle entre les deux.
wp-env face à une configuration Docker maison
| Critère | wp-env | Docker Compose maison |
|---|---|---|
| Mise en place | Très rapide, un seul fichier JSON | Plus de travail initial |
| Personnalisation fine | Limitée aux options prévues | Totale |
| Adapté à un site complet en production | Non, pensé pour un plugin ou thème isolé | Oui |
| Cohérence avec les versions cœur de WordPress | Excellente, maintenu par la même équipe | Dépend de la configuration |
Les limites qu’on a rencontrées
wp-env est clairement pensé pour développer un plugin ou un thème isolé, pas pour reproduire un site WordPress complet avec sa configuration serveur spécifique. Sur un projet avec des besoins de configuration Nginx particuliers, ou plusieurs plugins tiers à installer avec des versions précises, on a dû revenir à une configuration Docker Compose maison, plus flexible mais plus longue à mettre en place.
wp-env excelle sur un cas d’usage précis : développer un plugin ou un thème de blocs en isolation, avec une version de WordPress maîtrisée. Dès que le besoin dépasse ce périmètre, une configuration sur mesure reprend l’avantage.
En résumé
Pour développer un bloc Gutenberg ou un thème de blocs, wp-env offre la mise en place la plus rapide et la plus cohérente avec les outils officiels de l’équipe WordPress. Pour un site complet avec des besoins de configuration serveur spécifiques, une configuration Docker maison garde l’avantage de la flexibilité. Les deux approches ne s’opposent pas vraiment : on choisit l’une ou l’autre selon qu’on développe un composant isolé ou un site dans son ensemble.
