Un bacÀsable pour tester et développer à partir de Retraceur

Si par rapport à Node.js, PHP présente l’avantage d’être une technologie Web très répandue chez les hébergeurs, il est nettement moins pratique que Node.js pour rapidement construire son environnement de développement local.

Depuis que je me suis lancé dans le développement Web, il y a un peu plus de 25 ans, j’ai testé différentes solutions pour équiper ma machine d’un tel environnement : je viens enfin de trouver ma meilleure formule !

Cerise sur le gâteau, cette formule pourrait aussi contribuer à accélérer l’essor de Retraceur.

Logiciels, configurations avancées et virtualisation

Au tout début de mon apprentissage du développement Web, j’avais une machine équipée de MS Windows 98. La solution logicielle s’est alors révélée particulièrement pratique : easyPHP a accompagné mes premières lignes de code. Lorsque j’ai fait évoluer ma monture pour chevaucher un Tigre, j’ai continué à tester mon code avec une solution logicielle adaptée à ce nouvel équipement : mamp (Mac – Apache – MySQL -PHP).

Et puis, je me suis rendu compte qu’OSX intégrait en natif Apache et PHP. Plutôt que de doublonner ces deux briques de mon environnement de développement, j’ai donc opté pour leur configuration avancée, que j’ai simplement complétée avec MySQL.

Seul hic : dès qu’une mise à jour majeure d’OSX était installée, elle écrasait mes réglages et il fallait rétablir ma config… Plutôt agaçant 😡.

En parallèle, du fait de mon investissement dans l’organisation de journées de contributions à WordPress^® sur Paris (2017, 2018 et 2019), je me suis intéressé au projet VVV. C’était à l’époque la solution retenue pour faciliter l’embarquement des nouveaux·elles contributeur·rice·s. Après avoir installé ses dépendances, Vagrant et VirtualBox, une simple ligne de commande permet de virtualiser son serveur à partir d’un fichier de configuration. S’ensuit, alors, lors du premier lancement, une longue, très longue étape d’installation.

Comparé aux 2,5 minutes nécessaires pour rétablir ma configuration après une nouvelle version d’OSX, le temps nécessaire au premier lancement de VVV était tel que je ne l’ai manipulé que lors de ces journées, afin de me conformer aux consignes communautaires.

Toujours en parallèle, du fait de mon investissement dans le développement du projet BuddyPress^®, je me suis également intéressé à Docker lorsqu’il a été question de migrer l’environnement de tests unitaires du projet depuis Travis vers des actions GitHub. Au-delà de ces travaux, je n’ai pas accroché à cette autre manière de virtualiser son environnement de développement : la nécessité de télécharger l’utilitaire « Docker desktop » et de lui octroyer 6 Go d’espace disque y est certainement pour quelque chose.

Mon environnement de développement de prédilection a pris du plomb dans l’aile lorsqu’il s’est agi de mettre à niveau l’OS de ma machine pour Monterey (version 12 de macOS). Apple a en effet retiré PHP de son équipement par défaut 😡. J’ai alors fait la connaissance d’Homebrew : il m’a permis de facilement récupérer le PHP qui s’était envolé et de remplacer MySQL par MariaDB. Dans la même veine pour un vieux coucou que j’ai recyclé et qui est scotché sur OSX High Sierra, j’utilise également MacPorts.

Node.js et WebAssembly

J’ai découvert Node.js lorsque j’ai commencé à sérieusement contribuer au projet BuddyPress^® vers 2013. À l’époque, il n’était pas question d’exploiter tout le potentiel de cet environnement d’exécution JavaScript mais plutôt de fournir à Grunt.js la dépendance nécessaire à son fonctionnement. Grunt.js nous permettait d’automatiser des tâches annexes telles que la minification des feuilles de style et des scripts JavaScript, notamment ceux de jQuery. Vers la mi-2017, lorsque j’ai fait mes premiers pas avec ReactJS – pour ne pas rater le train innovant de l’éditeur de blocs du projet Gutenberg – Node.js gardait ce statut de dépendance pour l’empaqueteur de modules Webpack (utilisé pour construire les modules React de l’éditeur de blocs). Node.js était devenu quoiqu’il arrive un outil essentiel de mon « setup ».

Fin 2024, lorsque j’ai quitté l’équipe de développement de BuddyPress^® et la communauté WordPress^® – pour me libérer d’une gouvernance devenue incompatible avec mon éthique personnelle – mes recherches pour trouver un successeur à ce CMS pour mon site personnel m’en ont plus appris sur tout le potentiel de Node.js en particulier lorsqu’il était combiné avec MongoDB, Express.js et React : c’est à dire la pile MERN (qui est généralement associée au concept de développement « full-stack »). Il est effectivement séduisant d’utiliser un seul langage, JavaScript, pour concevoir les parties serveur et cliente d’une application Web : pourquoi multiplier les langages lorsque l’un d’entre eux permet de couvrir toute la pile ?

Sauf qu’avant de tourner le dos à PHP (après plus de 25 années de fidélité), il m’a semblé important de comparer l’accessibilité de l’hébergement de projets PHP Vs Node.js. Et sur ce plan, PHP conserve un avantage considérable : il reste très largement disponible chez les hébergeurs.

Les statistiques d’août 2026 issues de W3Techs sur le sujet sont assez éloquentes : JavaScript (7,2%) est quasiment 10 fois moins utilisé que PHP (70,2%) ! J’ai donc décidé de rester en éveil sur Node.js tout en gardant PHP comme langage serveur pour motoriser mon projet : j’ai finalement choisi de forker WordPress^® pour me délivrer du « MullenWeb » et donner naissance à Retraceur.

Concernant WebAssembly, je n’ai réellement fait sa connaissance que très récemment, alors même que je l’avais déjà utilisé sans le savoir, par l’intermédiaire de wp-now (aujourd’hui abandonné) puis de WP Playground. Ces deux outils utilisent WebAssembly pour permettre notamment d’exécuter PHP et SQLite depuis JavaScript, y compris avec Node.js.

Lorsque j’ai investi dans une nouvelle machine équipée d’une puce Apple Silicon, pour continuer de bénéficier des dernières évolutions de son OS, j’ai complètement revu ma manière de bâtir mon environnement de développement et donné à Node.js une place centrale.

Je me suis rendu compte de la rapidité et de la simplicité de mise en route du couple Node.js / WebAssembly en concevant bacÀsable, d’abord comme un fork de wp-now, avant de le faire évoluer en une surcouche de WP Playground adaptée à Retraceur.

Ainsi, si PHP reste remarquablement pertinent pour héberger Retraceur, Node.js est devenu remarquablement pratique pour le développer. Et WebAssembly permet finalement de faire le pont entre les deux.

Conception orientée auto-satisfaction !

bacÀsable a d’abord été très égoïstement conçu pour satisfaire mon besoin de simplification et d’optimisation de l’environnement de développement de Retraceur : « imath’s needs by design ».

Je m’étais interdit de reproduire sur ma nouvelle machine les montages éprouvés lors de mes 25 premières années d’apprentissage. Cette fois-ci, je ne recommencerai à développer qu’à partir du moment où JavaScript me permettra de tout faire depuis mon environnement de développement.

En fait, je me suis volontairement mis cette pression pour commencer à concrètement progresser dans ma véritable prise en main de Node.js.

J’ai assez vite découvert PHP-WASM, un projet permettant d’exécuter PHP grâce à WebAssembly. Cela m’a notamment rappelé que cette technologie était à la base de WP Playground.

Alors, dans mes souvenirs, comme l’interface de WP Playground ajoutait toute une couche dont je n’ai pas besoin, j’ai estimé qu’il ne cadrait pas tout à fait avec ma quête d’une approche très directe. Mon objectif est bien d’immédiatement lancer mon navigateur sur mon site de développement Retraceur, suite à la saisie d’une commande de terminal. Aussi, en poussant mon inspection du dépôt GitHub de ce terrain de jeu, il m’a semblé que l’outil wp-now constituait un bon point de départ à partir duquel itérer.

Ainsi, la version 0.9.0 de bacÀsable, un fork de wp-now, m’a permis, après deux mois de développement, de disposer de mon premier environnement de développement basé sur Node.js et WebAssembly. La fidélité du comportement de Retraceur et, surtout, sa rapidité d’exécution avec bacÀsable, comparées à celles de mes anciens environnements, se sont révélées assez convaincantes.

Deux exceptions ont cependant compliqué mes tests lorsque je développais des améliorations de l’administration de la santé du site ou de l’API de découverte introduite dans Retraceur 4.0.0.

La première concernait file_get_contents(), dont l’utilisation provoquait une erreur fatale empêchant l’affichage de l’écran d’administration. La seconde était liée à fetch_rss(), dont l’utilisation provoquait une erreur interrompant la récupération des versions disponibles d’une extension ou d’un bloc tiers.

J’ai un temps tenté de résoudre ces deux anomalies avant de tomber sur cet article. Il m’a fait réaliser deux choses. D’une part, wp-now était désormais déprécié : poursuivre le développement de bacÀsable sur cette base aurait été prendre un risque inutile. D’autre part, j’étais passé à côté d’une information importante : Playground mettait à disposition une interface en ligne de commande (ou « CLI »).

J’ai donc complètement revu ma copie et opté pour l’ajout d’une surcouche à cette interface. Ce qui s’est d’ailleurs révélé plus rapide en termes de développement et plus fiable en termes de comportement puisque les deux exceptions évoquées plus tôt se sont volatilisées !

bacÀsable 1.0.0

Cette première version stable offre aux utilisateur·rice·s de la version 22 (ou ultérieure) de Node.js une mise sur orbite « éclair » de leur environnement pour tester Retraceur, y contribuer et/ou développer à partir de son cadre des extensions / blocs / thèmes via une seule commande :

npx @retraceur/bacasable start

Cinq usages pour une seule commande

L’un des objectifs de bacÀsable était de ne pas avoir à mémoriser une multitude de commandes selon ce que l’on souhaite développer. Il suffit de se placer dans le répertoire du projet et de lancer la commande précédente : bacÀsable analyse son contenu et détermine automatiquement le mode à utiliser.

Développer une extension

Dans le répertoire d’une extension, bacÀsable détecte automatiquement qu’il s’agit d’une extension (ou d’un bloc) à partir de l’en-tête PHP de son fichier principal et le monte directement dans /wp-content/plugins de l’environnement Retraceur.

Il devient ainsi possible de travailler sur une extension comme si elle était installée dans une véritable instance de Retraceur, sans avoir à installer au préalable PHP, une base de données ou un serveur Web, fantastique !

cd mon-extension
npx @retraceur/bacasable start

Développer un thème

Le principe est identique pour un thème basé sur des blocs : la présence d’un fichier style.css contenant l’en-tête du thème suffit à bacÀsable pour l’identifier et le monter automatiquement dans /wp-content/themes.

cd mon-theme
npx @retraceur/bacasable start

Travailler sur plusieurs extensions ou thèmes

Lorsque le répertoire courant est /wp-content, bacÀsable peut également l’utiliser directement. C’est particulièrement pratique pour travailler sur un ensemble cohérent d’extensions et de thèmes sans avoir à les installer individuellement dans une instance de Retraceur.

cd mon-contenu
npx @retraceur/bacasable start

C’est de plus une configuration que je vous recommande fortement pour être également en mesure de travailler sur la traduction de votre extension, de votre bloc ou de votre thème, grâce à l’ajout des répertoires /wp-content/languages/plugins/ et/ou /wp-content/languages/themes/.

Contribuer au code de Retraceur

bacÀsable sait reconnaître une copie locale du dépôt de Retraceur. Dans ce cas, aucune nouvelle version de Retraceur n’est téléchargée : c’est directement le code présent sur la machine qui est utilisé.

cd ~/projets/retraceur/coeur
npx @retraceur/bacasable start

Cette possibilité est évidemment celle que j’utilise le plus souvent pour maintenir Retraceur.

Contribuer aux tests des futures versions de Retraceur

L’option --retraceur=numéroVersion de la commande est d’autant plus intéressante qu’au delà de tester ses créations avec des versions spécifiques de Retraceur, il devient possible de tester des pré-versions !

Par exemple, il suffit de préciser la version bêta ou candidate souhaitée :

mkdir testRetraceur4-0-0-beta1
cd testRetraceur4-0-0-beta1
npx @retraceur/bacasable start --retraceur=4.0.0-beta1

D’autres options sont disponibles pour vous permettre de personnaliser votre environnement, je vous invite à les découvrir depuis le fichier README du dépôt GitHub de bacÀsable.

Un nouvel accélérateur pour Retraceur

L’introduction de l’API de découverte de Retraceur dans sa version 4.0.0 constitue un premier accélérateur de son adoption : s’il devient plus simple d’installer et de maintenir à jour des extensions ou des blocs, cela facilite la personnalisation des fonctionnalités de son site personnel.

En plus de simplifier mon environnement de développement, bacÀsable pourrait constituer un second accélérateur : s’il devient beaucoup plus facile de tester Retraceur avant de l’adopter, il augmente aussi sa capacité à vous convaincre 😉.

Crédits de la photo en une Rashid Sadykov sur Unsplash

NB : Les marques WordPress^® & BuddyPress^® sont la propriété intellectuelle de la Fondation WordPress. L’utilisation des noms WordPress^® & BuddyPress^® dans cet article est uniquement à des fins d’identification et n’implique pas une approbation de la part de la Fondation WordPress.