Proposal: Add config option to disable DI definition change cache invalidation `invalidateResultCacheOnDiDefinitionChange`

[santysisi]

Hi 👋 First of all, thank you for the great work on PHPStan and the Symfony extension!

We are working on integrating result cache in our project to speed up analysis times. However, we noticed that the cache is invalidated very frequently, which reduces its effectiveness in most of our development workflows.

After some investigation, we identified the source of this behavior to be the feature added in this PR

We completely understand the value of this feature, it ensures the cache is invalidated when DI definitions change, which is especially important for production builds or CI pipelines to guarantee correctness.

However, in our development setup, this behavior is too aggressive. The DI container in our Symfony app changes very frequently , and as a result, the cache is invalidated most of the time. This defeats the purpose of caching during active development.

We suggest introducing a new configuration option (which was once discussed in the original PR but never merged):

[ruudk]

Thank you for raising this. I've had so many situations where I thought "why does PHPStan suddenly do a full analysis from scratch?" and then remembering this feature being the cause for it. Sometimes, I make changes to services that are covered by Symfony's Autowire and that triggers a rebuild. For example, I inject a new dependency into a class, or I add an attribute.

Most of the time, this does not affect PHPStan at all. I would say, rarely it does. In our setup, we have to enable the Symfony Container integration for dead-code-detector to work. Besides that, we rarely fetch services on a container, only in a few tests. If it wasn't for dead-code-detector I would have already turned off the Container support in order to prevent this cache invalidation from happening.

So I'm 👍 for an option to disable this! 😁

[ondrejmirtes]

The solution isn't to disable this key altogether, but instead take a look at the dumped container and do a smarter hash of the contents - e.g. change the hash only when there's a chance it can have impact on PHPStan's results.

[santysisi]

Hi, thanks for your response!

First of all, I want to mention that I don't have deep knowledge of PHPStan, so I apologize if anything I say is incorrect.

While looking through the project, I noticed a couple of things that might be worth considering (though I might be wrong):

1. Removing the 'alias' key from $services in SymfonyContainerResultCacheMetaExtension
   I observed that the getAlias method is only used in the XmlServiceMapFactory class, and it's primarily used to create new Service and add this new Service to the $services. It seems like the 'alias' key might not be necessary anymore, since a new $service will be created if this change is relevant.
2. Reducing the size of $serviceTags in SymfonyContainerResultCacheMetaExtension
   I observed that the getTags method is only used in the In the MessageMapFactory class, and it looks like the getTags method only considers tags with the name 'messenger.message_handler' and the attribute 'handles'. Based on this, we might be able to reduce the size of $serviceTags by filtering out only the tags with that specific name and attribute

Again, I don't have a deep understanding of the project, but if you agree with these changes, I'd be happy to work on a PR.

Thanks again!