Hafiq Iqmal a publié cette semaine un essai pratique de CPX v2, et au milieu de ses résultats de test se cache la phrase qui devrait changer la façon dont on parle de cet outil : quand il a lancé cpx pint dans une démo Laravel 13 toute fraîche, CPX a utilisé la version de Pint que ce projet avait épinglée. Pas la dernière release, pas un build mis en cache globalement — celle que le lockfile dit que l'équipe a validée. Ma position : ce seul comportement vaut plus que tout ce que CPX v1 faisait réuni, et l'ancien pitch d'ascenseur est désormais carrément trompeur.

L'ancien pitch, pour mémoire, c'était que CPX est à Composer ce que npx est à npm. C'était un bon pitch précisément parce qu'il ne demandait aucune explication. Mais il présentait aussi CPX comme un wrapper de confort : lancer un outil une fois, ne pas polluer composer.json, passer à autre chose. Les wrappers de confort, c'est sympa. C'est aussi exactement le genre de chose qui pourrit ton workflow en douce, parce que « l'exécuter une fois sans l'installer » veut généralement dire « exécuter la version qui s'est résolue par hasard aujourd'hui ».

Quiconque a déjà débogué une guerre de formatage connaît le scénario de l'échec. Ton run ponctuel de Pint en local reformate quarante fichiers. La CI, qui tourne avec la version épinglée du projet, les reformate dans l'autre sens. Personne n'a changé une ligne de code, mais le diff s'agite, le hook de pre-commit se dispute avec le pipeline, et quelqu'un finit par épingler l'outil partout, par épuisement — ce qui ruine tout l'intérêt d'un runner éphémère. Un exécuteur ponctuel qui ignore les versions épinglées du projet ne t'épargne pas une installation ; il repousse un conflit de merge.

Le deuxième comportement de la v2 testé par Hafiq, c'est cpx exec qui démarre Laravel avant d'exécuter un fichier PHP jetable. Ça gratte une vraie démangeaison : le script de dix lignes qui a besoin du conteneur et de tes modèles Eloquent mais qui ne mérite absolument pas de devenir une commande Artisan enregistrée, avec une signature, une description et une place à vie dans ton kernel console. Tinker couvre le cas interactif ; ceci couvre le cas « j'ai un fichier, exécute-le simplement avec l'appli chargée ». Un petit truc qui supprime une cérémonie franchement agaçante.

Maintenant, le contre-argument honnête, parce qu'il est solide : la conscience implicite du contexte, c'est de la magie, et la magie coupe dans les deux sens. Si cpx pint se comporte différemment selon le répertoire où tu te trouves, alors la même commande n'est plus la même commande. Un collègue qui colle des instructions dans un chat ne peut pas savoir ce que ton invocation fera réellement. Il y a une raison pour laquelle pas mal de développeurs préfèrent vendor/bin/pint précisément parce que c'est ennuyeux et sans ambiguïté — le chemin lui-même documente d'où vient le binaire.

Je penche quand même du côté « conscient du projet », et voici pourquoi : l'ambiguïté était déjà là. Le choix n'a jamais été « explicite contre implicite ». C'était « implicitement faux contre implicitement juste ». Un runner à la v1 qui attrape silencieusement une version arbitraire est tout aussi magique qu'un runner qui lit ton lock — sauf qu'il résout l'ambiguïté contre ton projet au lieu de la résoudre pour lui. Prendre par défaut ce que le dépôt a épinglé est le comportement le moins surprenant possible, parce qu'il correspond à ce que font déjà la CI, tes collègues et ton déploiement. Si je veux une autre version précise, c'est ce cas-là qui devrait m'obliger à le dire.

Le fait qu'il s'agisse désormais d'une réécriture détenue par Laravel plutôt que d'un projet perso compte aussi. Pas parce qu'un logo rend le code meilleur, mais parce que les outils de workflow vivent ou meurent selon leur maintenance : ils sont sur le chemin de chaque développeur de l'équipe, et un exécuteur abandonné est pire que pas d'exécuteur du tout. Une gouvernance assurée par une organisation avec une équipe salariée et un rythme de releases change le calcul quand il s'agit de l'adopter dans les docs d'outillage partagées, les Makefiles et les guides d'onboarding — les endroits où tu ne veux vraiment pas écrire « d'abord, installe ce truc qu'un type a arrêté de mettre à jour ».

Alors voilà où j'aimerais sincèrement t'entendre, parce que mon échantillon se limite à mes propres projets : laisserais-tu entrer un runner conscient du contexte comme cpx pint dans ta CI et dans tes docs pour contributeurs, ou traces-tu la ligne aux scripts dans composer.json et au chemin explicite vendor/bin — et si c'est la deuxième option, est-ce une vraie inquiétude de reproductibilité, ou un réflexe forgé par des années d'outils qui devinaient de travers ?