Le tooling JavaScript de WordPress — @wordpress/scripts en tête — s’appuie sur npm par défaut, et la documentation officielle continue d’en faire son exemple de référence. Mais deux alternatives se sont installées durablement dans l’écosystème JavaScript plus large : pnpm, connu pour son économie d’espace disque, et Bun, qui promet une vitesse d’installation et d’exécution nettement supérieure. Nous avons testé les trois sur un même thème block-first, pour voir ce qui change concrètement sur un projet WordPress plutôt qu’en benchmark abstrait.
Le projet de test : un thème avec une dizaine de blocs personnalisés, compilé via @wordpress/scripts, avec un package.json comportant une trentaine de dépendances directes et plusieurs centaines en comptant les transitives.
Vitesse d’installation
Sur une installation à froid (sans cache local), Bun s’est montré nettement le plus rapide, suivi de pnpm, npm fermant la marche. L’écart se réduit fortement une fois le cache local en place, ce qui relativise l’intérêt du gain sur des postes de développeurs qui réinstallent rarement de zéro. L’écart reste en revanche significatif en CI, où chaque exécution repart souvent d’un cache partiellement froid.
| Gestionnaire | Installation à froid | Installation avec cache |
|---|---|---|
| npm | Référence | Référence |
| pnpm | Nettement plus rapide | Plus rapide |
| Bun | Le plus rapide | Comparable à pnpm |
Compatibilité avec @wordpress/scripts
C’est le critère qui compte le plus pour un projet WordPress, et c’est aussi le plus rassurant : @wordpress/scripts ne fait aucune hypothèse sur le gestionnaire utilisé pour installer les dépendances. Une fois node_modules peuplé, les commandes wp-scripts build, wp-scripts start et wp-scripts test-unit-js fonctionnent à l’identique, quel que soit l’outil qui a posé les fichiers. La compatibilité se joue donc entièrement en amont, à l’étape d’installation.
Avec pnpm, le point d’attention concerne son mode de résolution strict des dépendances : par défaut, pnpm empêche un paquet d’accéder à une dépendance qu’il n’a pas explicitement déclarée dans son propre package.json, même si elle se trouve ailleurs dans l’arbre. Certaines extensions ou configurations Webpack tierces qui reposent sur des dépendances non déclarées explicitement (des « dépendances fantômes ») peuvent échouer à ce moment précis, avec une erreur de module introuvable qui n’apparaîtrait jamais sous npm.
Workspaces pour un monorepo d’agence
Pour une agence qui gère plusieurs paquets internes dans un même dépôt (thème parent, plugins maison, configuration de build partagée), les trois outils proposent un mécanisme de workspaces, mais avec des syntaxes différentes :
{
"name": "agence-monorepo",
"workspaces": ["packages/*", "sites/*"]
}
Cette déclaration fonctionne telle quelle avec npm et Bun. pnpm demande en revanche un fichier séparé, pnpm-workspace.yaml, plutôt qu’une clé dans package.json :
packages:
- 'packages/*'
- 'sites/*'
Sur ce point, pnpm impose une convention supplémentaire à apprendre, mais son modèle de liens symboliques entre paquets internes reste le plus rigoureux des trois pour éviter qu’un paquet du monorepo importe accidentellement une version différente d’une dépendance partagée.
Intégration en CI
Pour GitHub Actions, les trois gestionnaires disposent d’un cache intégré via l’action officielle actions/setup-node (npm et pnpm, via l’option cache) ou via l’action dédiée oven-sh/setup-bun pour Bun. La configuration la plus courante que nous utilisons pour pnpm :
- uses: pnpm/action-setup@v4
with:
version: 9
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- run: pnpm run build
L’option --frozen-lockfile (équivalent de npm ci) est essentielle en CI : elle refuse l’installation si le fichier de verrouillage ne correspond pas exactement au package.json, plutôt que de le régénérer silencieusement.
Verrous et écosystème
- npm reste le choix par défaut de la documentation officielle WordPress et de la quasi-totalité des tutoriels disponibles en ligne, ce qui simplifie l’intégration de nouveaux développeurs ;
- pnpm apporte un gain d’espace disque réel sur un poste qui héberge de nombreux projets WordPress, grâce à son magasin de paquets partagé entre projets ;
- Bun est encore le moins éprouvé des trois sur des configurations Webpack complexes héritées de
@wordpress/scripts, certaines extensions de build plus anciennes n’étant testées qu’avec Node.js et npm.
Sur un nouveau projet solo, le gain de vitesse de Bun est réel mais rarement décisif. Sur un parc de dizaines de projets partagés en agence, c’est l’économie d’espace disque de pnpm qui a fini par nous convaincre.
Notre verdict
npm reste le choix le plus sûr par défaut pour un projet isolé ou une équipe qui découvre l’écosystème JavaScript de WordPress : c’est ce que la documentation utilise, et c’est ce qui pose le moins de questions. pnpm devient pertinent dès qu’un poste ou un serveur de CI héberge plusieurs projets WordPress en parallèle. Bun mérite d’être testé sur un projet non critique avant adoption, le temps de vérifier que toute la chaîne de build (extensions Webpack comprises) s’y comporte comme prévu.
