#23173 RFC: add an experimental `php` backend New discussion created by TiagoGoddard I've been interested in a

php

backend that brings first-class support for PHP projects, integrating Composer, PHPUnit, and static analysis into the Pants ecosystem. The

php

backend The

php

backend would be functionally similar to the existing

javascript

,

cc

, or

go

backends. It would manage third-party dependencies via Composer and provide standard targets for PHP sources, tests, and packaged binaries alongside autoload files. I imagine this backend would be most useful for teams managing mixed-language environments with PHP microservices or APIs, maybe some legacy monoliths too or frameworks like Laravel. It could also be highly useful to audit and format PHP codebases uniformly. Proposed Approach: Since I am just starting to scope this out, and I'm new to Pants in general, I haven't written any code yet. However, I envision the core functionality focusing on: • Source Mapping: Taking a

php_sources

target and mapping internal dependencies based on directory structures. • Dependency Management: Creating a

composer_requirements

macro to parse

composer.json

and

composer.lock

files, which would generate individual third-party targets for vendor packages. • Hermetic Testing: Implementing a

php_test

runner that extracts the required closure of source files and invokes

PHPUnit

in an isolated, temporary environment. Note As far as I know, there aren't many build systems that handle PHP so this could actually prove a lot of trouble (I could be wrong though!). Warning Composer itself doesn't break hermeticity, but it is also not hermetic by default because it relies on the system's PHP installation and global environment, that can make caching unreliable. My goal for this backend would be to handle toolchain structure and isolate the

vendor

directory requirements per target, similar to how

javascript

handles package.json files. This ensures that a cache hit for a specific microservice's test suite remains accurate regardless of what other PHP projects exist in the repository or how currently installed tools handle it. Potential scope of the

php

backend: I'm calling this a

php

backend to encapsulate the entire PHP ecosystem. In figuring out how best to analyze and build PHP codebases in a strict environment, handle estabilished frameworks like Laravel, Wordpres and Zend, these tools and features seem like natural fits under a backend, and PHP already have tools that could help with most required features. Scopes that could be done: • Dependency Inference: Code to parse

use namespace\Class;

and also require/import statements in

.php

files to automatically infer dependencies between internal Pants targets, eliminating manual

BUILD

file boilerplate, should probably handle

composer.json

and

compoer.lock

files too. • PHP CLI Lint: PHP itself has a standard code formatting and style enforcement tool. • Packaging: A tool for building PHAR (PHP Archive) files. This could be mapped to

package

standalone executable binaries for CLI tools written in PHP. • Testing: PHP has mature testing tools like PHPUnit and Pest • Other tools: PHP is a mature language and tools like PHPStan / Psalm for example coud work as static analysis tools and could be wired into a

check

goal to enforce type safety and catch errors across the repository before builds or deployments. Request for feedback • Does any of this sound good? Is there a large enough intersection of Pants users and PHP developers managing mixed-language repositories to warrant this? • If I were to start building this, which tools or goals (

test

,

lint

,

package

) would be the most valuable for an MVP? • Hopefully, there is interest in the creation of

pants.backend.experimental.php

, and would anyone (besides me) be willing to collaborate or test it? pantsbuild/pants