I'm working on a Twig extension for PHPStan that is able to compile Twig AST to PHP AST (in memory) and allows PHPStan to analyze those AST. Others have tried this in the past as well. But they tried to optimize the compiled code from Twig itself. And they worked from the PHP point that tries to render a template.

I do this differently. I generate custom AST code that is only needed for analysis. That means that the code is not able to actually render the Twig template.

I know you said that PHPStan is not suitable for that. I was being stubborn 😁 and was able to get my POC working. It works pretty well. The extension registers twig as a file type and injects a TwigSupportingParser in $originalParser of defaultAnalysisParser. The TwigSupportingParser then decorates pathRoutingParser.

One of the big advantages of doing this in memory (as opposed to first writing this to a temporary PHP file) is that the errors are reported on the original filename + line numbers. When converting from Twig AST I create new PhpParser tokens that have the original line number as attribute. That also means that running phpstan analyze templates/index.twig (or the whole template directory) also works. Another advantage is that I can distribute this as extension, instead of having to create my own whateverstan executable that has PHPStan inside it.

Using a custom error formatter to reformat those errors is not an option for me. The errors that are generated should be reported on the original file + line. Otherwise baselining will not work either. It also makes it complicated for people that use a custom error formatter (like we do).

Of course, there are also drawbacks to the in memory approach. I believe it's also why you said that PHPStan is not suitable for this. For example, using @phpstan-ignore will not work, because of the special way these comments are discovered in RichParser. This could potentially be improved by allowing to ignore certain errors also on the Node (via attribute).

Another downside of doing this inside a PHPStan extension, is that if you run PHPStan on the highest levels together with bleeding edge and phpstan/phpstan-strict-rules, you get a lot more errors in the compiled PHP Twig templates. Twig is very loose with strictness regarding types and checking. Maybe with a custom Twigstan that would be easier to do? Somehow take the project's PHPStan config without phpstan/phpstan-strict-rules extension?

If we could create an Error Processor Extension that is able to ignore errors but also modify errors by returning a new error object, it could help my project (and other projects like Bladestan). It would allow to compile from any language into a temporary PHP file. While doing that, we keep track of a mapping between PHP line numbers and the original file line numbers. The Error Processor Extension can then replace the errors by looking at the temporary PHP filename + line number inside the mapping, and then search for the original Twig filename + line number.

PS: While exploring this integration in PHPStan, I've become more familiar with how things work and are designed/set up. I just want to express my immense respect for the way this project has been created. The various building blocks come together and function exceptionally well. 💙

I'm not very keen on overriding the defaultAnalysisParser in config. It's not an "official extension point" PHPStan supports. The downside of this hack is that you can have only one extension at a time that does that. Another obvious one is that I might reshuffle these parser services in PHPStan itself because of some bugfix or other improvement, breaking your hack.

I still think this is achievable with your own executable, resulting in a better working state. To address your concerns:

• You could use your own error formatter. This is how: Twigstan executes PHPStan, PHPStan outputs errors in JSON. Twigstan changes filepaths in the JSON array and calls hypothetical reformat-errors PHPStan command that would take JSON errors and used a registered PHPStan error formatter. (I thought this already existed, someone must have asked for it in the past. It's very easy to add and I could do it.)
• @phpstan-ignore could work if you correctly preserved it from .twig to compiled .php analysed by PHPStan.
• Baseline would work but the file paths in it would be to compiled .php files. Which is a cosmetic downside which could be addressed later. For example, baseline could become a feature of Twigstan - the .neon file would NOT be included by PHPStan config, but you could reimplement the right parts in Twigstan so that you'd have nicer paths in the baseline file. (And you'd be free to have a different file format for the baseline too.)
• Another point in favour of Twigstan is that you probably wouldn't want to reuse the whole PHPStan config, like level, extensions and so on. You could have phpstan-common.neon with the common config for both tools. And you'd want to run PHPStan separately anyway, and at that point it doesn't matter if you're analysing templates with vendor/bin/phpstan analyse twig.neon or vendor/bin/phpstan twigstan.

I just want to express my immense respect for the way this project has been created.

Thank you for your kind words! But I want to say I'm not a genius by any stretch of the imagination. This is mostly product of time (this is now PHPStan's 8th year) and solving user's needs based on feedback. I also had tremendous help from other awesome contributors (which I consider geniuses :))

There are other projects trying to achieve the same thing, like Bladestan or https://github.com/efabrica-team/phpstan-latte/ (which uses collectors to achieve similar things but it's also hacked together). I'm trying to persuade you to do the separate executable because it could be a template for other projects to follow. And I don't want it to be hacked together because otherwise it's prone to breaking and makes PHPStan maintenance harder.

Thanks so much for taking the time to guide me in this process. I agree that my hacks are brittle and might break with any new release of PHPStan. I will try to follow your suggestions and see how far I get.

Twigstan executes PHPStan

When you say this, do you mean that I just invoke vendor/bin/phpstan process with the arguments (like separate config etc)?
Or would you suggest to somehow use PHPStan's container and call it from PHP. I believe that's how Rector uses PHPStan. If you have any hints on how to do it, that would help. Otherwise I will see how far I get.

Yeah, I mean just call PHPStan with exec() or similar. That way you'll get a lot for free, like result cache and parallel processing.

If you get stuck I'm happy to get on a call with you for a few hours and figure it out!

Is your "twigstan" public @ruudk ? I would be really insterested trying it.