Explore possible collaboration with PHP;STEINS

[petrovo-as]

Description

While looking at php-typing-conformance, I came across PHP;STEINS:

https://github.com/rigortype/steins

PHPantom and PHP;STEINS have different primary goals, but there seems to be some meaningful overlap:

• both are written in Rust
• both build on Mago-related parsing infrastructure
• both implement advanced PHP/PHPDoc type inference
• both care about low-noise diagnostics
• PHP;STEINS has an LSP preview on its roadmap, while PHPantom already has a mature LSP implementation

I am not suggesting merging the projects or changing either roadmap.

It might simply be useful for the maintainers to be aware of each other and consider whether some areas could be shared or coordinated, for example:

type-system and conformance test fixtures

• PHP/PHPDoc semantics
• Mago-related parser work
• possibly supporting PHP;STEINS as an external analyzer backend in PHPantom in the future

Use case

Avoid duplicating difficult PHP type-system and static-analysis work where both projects are solving similar problems.

PHPantom could stay focused on editor intelligence, navigation, framework awareness, and LSP functionality, while PHP;STEINS could continue focusing on deeper static analysis.

Even limited cooperation, such as sharing conformance fixtures or discussing type-system edge cases, could benefit both projects without coupling their architectures.

Proposed solution

No response

Alternatives considered

No response

Code example

[AJenbo]

I'm well aware of the project and contribute a bit to there conformance test. As for collaborating I think you should ask @zonuexe PHPantom was already fairly well established when STEINS was started. I'm guessing they wanted to more directly mirror PHPstan.

[petrovo-as]

Thanks for the context, that makes sense.

I’ve already reached out to the STEINS project as well to see if there’s any room to join forces or share some effort between the projects.

Thanks again for the reply and for your work on PHPantom.

[zonuexe]

While there are other PHP type checkers written in Rust—such as mir/PHP-LSP and pzoom in addition to mago—each of them appears to focus on a different objective.

Although PHP;STEINS self-deprecatingly describes itself as a "parody," I view it less as a practical tool and more as an experimental sandbox for ideas. Currently, it serves two purposes: prototyping an effect checker built upon a type checker, and feeding back insights gained from Rigor—a system I am designing for Ruby—into the PHP ecosystem.

In the PHP world, tools like PHPStan, Psalm, and Phan have long coexisted, sharing basic PHPDoc syntax while never producing identical analysis results. Furthermore, while the standardization efforts for PSR-5 and PSR-19—drafted in 2018—have stalled, this outcome reflects a judgment by developers that the ecosystem grows best when individual tools evolve their own unique features and adopt ideas from one another as needed, rather than adhering to a rigid standard.

As suggested in this discussion, a broad consensus on PHPDoc syntax and semantics helps reduce cognitive friction for both developers and users—a goal supported by the maintenance of PHP Typing Conformance. Conversely, while sharing core components might seem logical, it may not be particularly effective, as it risks slowing down the pace at which individual tools evolve. I believe that common problems can be solved through mutual contribution and—when appropriate—imitation, as @AJenbo often practices.

[AJenbo]

Yeah that sort of fits my view as well. I haven't deep dived the STEINS's codebase yet so I don't know much about it's internals or exact scope, but what you are describing is also why PHPantom is build using some of Mago's component while implementing it's own variant of others. I still contribute findings back to Mago, PHPStan, PhpStorm_stubs, Phpactor, and provide feedback to the PhpStorm team when ever it makes sens. There is still a lot of active exploration going on in this space.

[zonuexe]

As a supplementary note to this discussion:

As I also mentioned in this issue comment, there is definitely room in the future to consider loosely coupled integrations. This could involve sharing smaller, non-core components or connecting features via inter-process communication or some form of API.

However, we don't have any concrete plans for this at the moment. Integrating Steins in its current state would likely just result in duplicate warnings alongside other tools, so this kind of collaboration would probably be something for the more distant future.

Ultimately, our collaboration will likely happen on an as-needed basis, rather than synchronizing our efforts purely for the sake of "integration."