in our projects we also do some ugly 'dance' to enable/disable extensions in some cases.
in our setup we "disable" the whole extension-installer with composer remove phpstan/extension-installer on a by-case basis and enable extensions manually with prepared dedicated phpstan.neon configs.

did you realize you can put extensions on a ignore list ?

did you realize you can put extensions on a ignore list ?

Yes but given that TwigStan runs within the project of the user, it won't make any difference. It would require people to disable the extension for normal PHPStan analysis as well.

Hey, I thought about this but I think it's against your interests.

PHPStan extensions are not just about extra rules. They are also about making analysis smarter (more precise type inference). I think that Twigstan should include user's PHPStan config and just override some stuff it needs. Otherwise you're at risk collecting information from PHP code (controllers etc.) with dumber analysis than PHPStan is usually capable of when analysing the cobase.

Because with the above in mind, you're now at risk of having some errors reported besides the things Twigstan itself reports (I mean the final CollectedDataNode rule that provides metadata to the error formatter), you should be a little bit more defensive and filter the errors reported by your own identifier.

If you do that then there's basically no harm in extra rules being run while Twigstan is doing its job collecting data for further execution.

Thanks. You're right, extensions have more benefits than just adding errors.

I will try to support the extension-installer out of the box, and manually ignore the errors reported by phpstan-strict-rules.

I can use this snippet to extract those identifiers (from time to time):

curl -s https://raw.githubusercontent.com/phpstan/phpstan/2.0.x/website/src/errorsIdentifiers.json |  jq -r '[ to_entries[] | select(.value | .[] | has("phpstan/phpstan-strict-rules")) | .key ] | unique[]'

@ruudk You should allow-list only your known identifiers, not exclude errors from phpstan-strict-rules. You'll get many more errors reported by other extensions as well.

It's not that simple. I want all errors to be reported. TwigStan does not have any custom errors at the moment. The compiled Twig templates are just PHP after all.

This is perfectly fine Twig code:

{{ user.id == object.id ? 'a' : 'b' }}

But it produces this error:

Loose comparison via "==" is not allowed.
💡 Use strict comparison via "===" instead.
🔖 equal.notAllowed

This is because Twig is not as strict as PHP (can be). So the compiled code is also not as strict.

Maybe I should just ignore these type of identifiers when I spot them. Instead of trying to ignore all identifiers from phpstan-strict-rules.

I get it, I thought you were talking about the collector run, not the final "error run" 😊

Yes indeed.

The collector run works great with:

level: null
customRulesetUsed: true

Now that the extension-installer is no longer disabled, this does give the type improvement, but does not produce any errors, only collected data.