RFC: add an experimental php backend

[TiagoGoddard]

I've been interested in a php backend that brings support for PHP projects, integrating Composer, PHPUnit, and static analysis into the Pants ecosystem instead of adhoc-tools.

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?

[cburroughs]

I have not used php in many years, but I'll try try to offer some really general thoughts.

• How much are you using php with Pants now? Is it with adhoc_tool? I think the farther you have gotten with that the more (A) you will understand Pants, and (B) have a good sense of which things (test, lint, etc) would be most valuable.
• I'd recommend starting in your own repo along the lines of A plugin for Rust #20119 That will give you the most room to experiment, try things out, and a faster "dogfood" path. (It is easier to get teammates to use Pants releases with an extra plugin than it is to get everyone to build Pants from source).

Good luck!

[TiagoGoddard]

Currently we have a decentralized repo and not using any tool besides platform specific ones on each project.
We are centralizing them in a monorepo with the intent of reducing diamond dependencies (i.e different projects with same vendor on different/conflicting versions).

We are in the process of making two different proof of concepts with both Bavel and Pants, regarding Pants we will do the proof of concept using adhoc_tool (not ready yet), but a plugin will probably be in the future if we move forward with it.

[benjyw]

So, my main question about all of this would be who owns and maintains this backend. None of the current Pants maintainers (to my knowledge) have much experience with PHP, or any current investment in it, so we are not in a good position to do this.

So what I'm really asking is - are you motivated enough to not just develop this but to own it going forward? :) Is this more of a personal project, or does your employer have a use case for this? Obviously in the latter case it's more likely that there could be resources and motivation for maintenance.

[TiagoGoddard]

I'm going to try my hand at a plugin probably, similar to what was done here: #20119 .
This is definitely a personal project currently, specially since my knowledge of Pants is basic at best. If it gets mature enough we can evolve it and start talks into incorporating it and how to best maintain it.