Les outils de build de WordPress sont sur le point de changer. Mais rassurez-vous, ce n’est pas une refonte brutale qui va casser vos flux de travail existants. Si vous utilisez @wordpress/scripts aujourd’hui, vous continuerez probablement à l’utiliser comme avant. Cependant, sous le capot, le moteur, la philosophie et l’expérience développeur évoluent.

La nouvelle solution s’appelle @wordpress/build, un outil de build plus rapide, basé sur les conventions, qui remplace la pipeline webpack/Babel, génère automatiquement les fichiers d’enregistrement PHP, et gère les scripts, modules et styles en une seule passe. GutenbergL'éditeur par blocs introduit dans WordPress 5.0, utilisant... More l’utilise déjà en interne. Le plan à long terme est qu’il devienne le moteur sous-jacent de @wordpress/scripts, ce qui signifie que tous les développeurs de plugins en bénéficieront.

Mais l’outil n’est pas encore totalement prêt pour tous les cas d’usage. Et c’est là que vous entrez en jeu.

Dans cet articleUn contenu dynamique et temporel (ex. : billets de blog) aff... More, nous allons décortiquer ce que fait @wordpress/build, pourquoi c’est important, et comment cela affecte les différents types d’utilisateurs de WordPress: des contributeurs cœur aux développeurs de blocs, en passant par les agences.

Qu’est-ce que @wordpress/build ?

@wordpress/build est un nouvel outil de build introduit par JuanMa Garrido et l’équipe cœur de WordPress. Il est conçu pour :

• Remplacer webpack + Babel par un moteur nettement plus rapide (actuellement esbuild).
• Découvrir automatiquement les packages JavaScriptUn langage de programmation utilisé pour créer des éléme... More, les routes d’administration et (bientôt) les blocs, plus besoin de points d’entrée manuels.
• Générer automatiquement les fichiers d’enregistrement PHP (build.php, scripts.php, etc.), fini l’enregistrement manuel des scripts et styles.
• Gérer les dépendances externes via un modèleUn fichier dans un thème qui définit comment différentes ... More de namespaces, rendant l’interopérabilité entre plugins transparente.

L’outil alimente déjà les plus de 100 packages de GutenbergL'éditeur par blocs introduit dans WordPress 5.0, utilisant... More. La prochaine étape est son intégration dans @wordpress/scripts pour que tous les développeurs WordPress en bénéficient.

Comment ça fonctionne (en termes simples)

Au lieu de configurer des points d’entrée webpack, vous suivez simplement des conventions de dossiers :

mon-plugin/
├── packages/          # Packages JavaScript (construits automatiquement)
├── routes/            # Routes de pages d’administration (expérimental)
└── blocks/            # Proposé : blocs découverts automatiquement

À l’intérieur de chaque package, vous ajoutez un package.json avec des indicateurs simples comme "wpScript": true. C’est tout.

Exécutez wp-build, et l’outil :

1. Découvre tous les packages.
2. Les bundle (avec esbuild, pas webpack).
3. Génère les fichiers PHP pour tout enregistrer auprès de WordPress.
4. Gère automatiquement les dépendances, plus de wp_enqueue_script ou de fichiers .asset.php à gérer manuellement.

Pourquoi c’est important

Pour les développeurs de blocs quotidiens

Vous utilisez @wordpress/create-block ou @wordpress/scripts. Bonne nouvelle : votre flux de travail ne changera probablement pas. Lorsque @wordpress/build deviendra le moteur par défaut, vous bénéficierez :

• De builds plus rapides (des minutes → des secondes).
• De moins de code boilerplate (plus d’enregistrement PHP manuel).
• D’une gestion plus intelligente des dépendances (les imports depuis d’autres plugins fonctionnent simplement).

Mais pour l’instant, restez sur @wordpress/scripts sauf si vous expérimentez. La migration se fera automatiquement plus tard.

Pour les développeurs de plugins avec plusieurs scripts ou pages d’administration

Si votre plugin a plusieurs points d’entrée (ex : une pageUn contenu statique (ex. : "À propos", "Contact") qui ne fa... More de réglages, un bloc, un script frontal), @wordpress/build mérite d’être évalué dès aujourd’hui. L’approche basée sur les conventions élimine la configuration webpack répétitive et l’enregistrement PHP fastidieux.

Exemple : Vous voulez une nouvelle pageUn contenu statique (ex. : "À propos", "Contact") qui ne fa... More d’administration ? Ajoutez un dossier sous routes/. Vous voulez un nouveau bloc ? Ajoutez un dossier sous blocks/ (une fois supporté). L’outil gère le reste.

Pour les agences et les constructeurs de produits

Si vous maintenez plusieurs plugins ou une grande bibliothèque de blocs personnalisés, le modèleUn fichier dans un thème qui définit comment différentes ... More de namespaces change la donne. Vous pouvez déclarer des dépendances externes à d’autres plugins (ex : WooCommerce) et @wordpress/build s’assurera automatiquement que les scripts se chargent dans le bon ordre, plus besoin de tableaux de dépendances manuels.

"wpPlugin": {
  "externalNamespaces": {
    "woo": { "global": "woo", "handlePrefix": "woocommerce" }
  }
}

Pour les contributeurs à Gutenberg

Vous utilisez déjà @wordpress/build lorsque vous exécutez npm start dans GutenbergL'éditeur par blocs introduit dans WordPress 5.0, utilisant... More. Comprendre la configuration wpPlugin et la résolution des externals vous aide à déboguer les problèmes de build et à contribuer plus efficacement.

Pour l’écosystème WordPress

Ce changement représente un virage philosophique : la convention plutôt que la configuration. WordPress absorbe la complexité dans les outils pour que les développeurs puissent se concentrer sur les fonctionnalités, pas sur les pipelines de build. C’est une victoire pour toute la communauté.