kphp VS Deptrac

It has a lot of limitations but KPHP is a PHP compiler that could fit your needs.

There are also https://github.com/VKCOM/kphp, but it lag quite a bit behind php

JIT is still so full of bugs for anything mildly complex, most static analysers don’t run on it without some weird behaviour and crashes (segfaults, core dumps, etc) that are hard for the average PHP dev to debug. It was a nice idea to help expand PHP to non-web applications but something like what’s being described here where code is transpiled except to a compiled language (like https://github.com/VKCOM/kphp) would be the best bet imo.

We invented a new concept of function colors and implemented it in our KPHP compiler.

Since 2013 we have a php 2 c++ compiler, kphp — it was a hip idea back then, and Facebook had something similar with hiphop

Server side they use kphp (Probably a modified version) https://github.com/VKCOM/kphp

You can also refer to [*PHP vs KPHP vs C++*](https://vkcom.github.io/kphp/various-topics/walk-through-php-kphp-cpp.html).

*[GitHub page](https://github.com/vkcom/kphp)* | *[Web-site (documentation)](https://vkcom.github.io/kphp/)*

Deptrac

Deptrac: Keep your architecture clean.

So far I've found some tools which I could piece together to accomplish enforcing module boundaries, probably run as part of an automated github action. - https://github.com/qossmic/deptrac Uses YAML to define any boundary, you can also use @internal to hide implementation classes. Seems like a good way to achieve what I want.

How about https://qossmic.github.io/deptrac/ ?

>I wonder: Is automatic DI even helpful? You save some lines of boilerplate but sacrifice control over the initialization-order and get a flat, messy, implicit dependency graph

Initialization order doesn't matter if your services are stateless. At least in our codebase, all of them are stateless, as it greatly simplifies reasoning about concurrent code (both in-process and between servers). Yes, it's easy to end up with a very a convoluted dependency graph under the hood, but I don't think it's a problem you really should care about. I mean, your code most likely already compiles to a very convoluted mess of machine code under the hood (with all the optimizations, ABI quirks etc.) and I doubt it matters to you much, as long as it does its job well and doesn't hinder your productivity.

If you are talking about messy dependency graphs from the architectural standpoint (someone can easily add a dependency in the constructor without thinking about the consequences), we use deptrac for our PHP monolith which can validate your architecture is clean at build time [0]

However, for our microservices written in Go, we decided to use manual DI to stimulate developers to prefer simpler design, otherwise our microservices could quickly turn to monoliths again.

[0] https://github.com/qossmic/deptrac

Deptrac is a static code analysis tool for PHP that helps you communicate, visualize and enforce architectural decisions in your projects.