mago

Ill preface my comment with saying: this might not be the best solution give the goal of your project to iteratively loop through and improve on the tests each round, and using deps would make that process longer/more complicated having to work potentially with another project. .....however..... mago, a static analyzer for php is written in rust and might be useful for gaining some "free" performance uplift: https://github.com/carthage-software/mago. iirc it splits out a far bit of its internals so they can be used by other projects (citation needed)

Thank you in advance for opening an issue for the panic—that's super helpful. You are 100% right about the documentation and managing expectations on the home page. That's a failure on my part, and based on your feedback, I'll make it a priority to be much clearer about the project's beta status, goals, and roadmap. The lack of @property and @method support was the single biggest source of noise on established codebases. The good news is that this is exactly what we've been focused on, and support for both was just merged in the past few hours: @method support is now quite robust: - https://github.com/carthage-software/mago/commit/c76795c30de... - https://github.com/carthage-software/mago/commit/dc333edb261... @property support is about 95% there, and we're ironing out the last few edge cases as we speak: - https://github.com/carthage-sof

Mago author here. Thanks for the feedback. You're right that the README should be clearer about the beta status and the current feature set. That's a great suggestion, and I'll get that updated. Regarding the errors you saw, I suspect the main culprit isn't a general lack of PHPDoc parsing, but rather the two biggest remaining features we're actively working on: support for magic _@method_ and _@property_ tags. Mago has full support for generics (@template), assertions (@psalm-assert*), conditional types, etc., but the absence of those two is definitely a major source of noise on established projects right now. They are our top priority and should land in the next beta release. On the topic of feature parity, you're right that it's a moving target. Our goal isn't to be a 1-to-1 clone of Psalm or PHPStan, but a different tool with its own

The README is quite ahead of reality: it never mention that Mago is still beta software. A roadmap to a first release was created 5 days ago, https://github.com/carthage-software/mago/issues/405. I've just tried to apply it to a medium-sized project, and it spitted tens of thousands of errors where phpstan and psalm don't see any. At first glance, it's because Mago does not parse phpdoc. In its current beta state, Mago is meaningless for all the big PHP projects, which are its main target. Mago might succeed, but I wouldn't bet on it. Its main selling point is that it promises to be faster than the usual static analysers-linters (phpstan and psalm). But if it does not reach feature parity with them, the speed gain probably won't convince PHP projects to drop the standard tools. Since phpstan and Co keep evolving, keeping feature parity wi

PHP is getting Mago (written in Rust). Repo: https://github.com/carthage-software/mago Announcement 9 months ago: https://www.reddit.com/r/PHP/comments/1h9zh83/announcing_mag... For now its main features are 3: formatting, linting and fixing lint issues. I hope they add package management to do what composer does.