Hafiq Iqmal publicó esta semana un análisis práctico de CPX v2 y, enterrada entre sus resultados de prueba, está la frase que debería replantear cómo hablamos de esta herramienta: cuando ejecutó cpx pint dentro de una demo recién creada de Laravel 13, CPX usó la versión de Pint que ese proyecto tenía fijada. No la última release, no alguna build cacheada globalmente — la que el lockfile dice que el equipo acordó. Mi postura: ese solo comportamiento vale más que todo lo que hacía CPX v1 junto, y el viejo discurso de venta ahora es directamente engañoso.

El viejo discurso, para que conste, era que CPX es para Composer lo que npx es para npm. Era un buen discurso precisamente porque no requería explicación alguna. Pero también presentaba a CPX como un envoltorio de conveniencia: ejecuta una herramienta una vez, no contamines composer.json, sigue adelante. Los envoltorios de conveniencia están bien. También son exactamente el tipo de cosa que pudre tu flujo de trabajo en silencio, porque 'ejecútalo una vez sin instalarlo' suele significar 'ejecuta la versión que casualmente se resolvió hoy'.

Cualquiera que haya depurado una guerra de formato conoce el modo de fallo. Tu ejecución local puntual de Pint reformatea cuarenta archivos. El CI, ejecutando la versión fijada del proyecto, los reformatea de vuelta. Nadie cambió una línea de código, pero el diff se agita, el hook de pre-commit discute con el pipeline y alguien acaba fijando la herramienta en todas partes por puro agotamiento — lo cual anula todo el sentido de un ejecutor efímero. Un ejecutor puntual que ignora los pins del proyecto no te está ahorrando una instalación; está aplazando un conflicto de merge.

El segundo comportamiento de v2 que probó Hafiq es cpx exec arrancando Laravel antes de ejecutar un archivo PHP desechable. Esto resuelve una molestia real: el script de diez líneas que necesita el contenedor y tus modelos de Eloquent pero que en absoluto merece convertirse en un comando de Artisan registrado, con firma, descripción y un sitio en tu kernel de consola para siempre. Tinker cubre el caso interactivo; esto cubre el caso de 'tengo un archivo, simplemente ejecútalo con la app cargada'. Es una cosa pequeña que elimina una ceremonia genuinamente irritante.

Ahora el contraargumento honesto, porque es fuerte: la conciencia implícita del contexto es magia, y la magia corta por los dos lados. Si cpx pint se comporta distinto según el directorio en el que estés parado, entonces el mismo comando ya no es el mismo comando. Un compañero que pega instrucciones en un chat no puede saber qué hará realmente tu invocación. Hay una razón por la que muchos desarrolladores prefieren vendor/bin/pint precisamente porque es aburrido e inequívoco — la propia ruta documenta de dónde sale el binario.

Yo sigo cayendo del lado de la conciencia del proyecto, y este es el porqué: la ambigüedad ya estaba ahí. La elección nunca fue 'explícito versus implícito'. Era 'implícitamente equivocado versus implícitamente correcto'. Un ejecutor al estilo v1 que agarra en silencio una versión arbitraria es exactamente tan mágico como uno que lee tu lock — solo que resuelve la ambigüedad en contra de tu proyecto en vez de a su favor. Usar por defecto lo que el repositorio tiene fijado es el comportamiento menos sorprendente disponible, porque coincide con lo que ya hacen el CI, tus colegas y tu deploy. Si quiero una versión distinta concreta, ese debería ser el caso que me obligue a decirlo.

También importa que esto sea ahora una reescritura propiedad de Laravel y no un proyecto paralelo. No porque un logo mejore el código, sino porque las herramientas de flujo de trabajo viven o mueren por el mantenimiento: se sientan en el camino de cada desarrollador del equipo, y un ejecutor abandonado es peor que ninguno. Que lo custodie una organización con un equipo remunerado y una cadencia de releases cambia el cálculo a la hora de adoptarlo en la documentación de tooling compartida, en los Makefiles y en las guías de onboarding — los sitios donde de verdad no quieres escribir 'primero, instala esta cosa que un tipo dejó de actualizar'.

Así que aquí es donde de verdad me gustaría escucharte, porque mi tamaño de muestra son mis propios proyectos: ¿dejarías entrar un ejecutor consciente del contexto como cpx pint en tu CI y en tu documentación para contribuidores, o trazas la línea en los scripts de composer.json y la ruta explícita vendor/bin — y si es lo segundo, es una preocupación real de reproducibilidad, o memoria muscular de años de herramientas que adivinaban mal?