Replies: 1 comment
-
Sounds good to me. I kind of intend to use it that way anyway. But I don't think it is at all necessary to drop the original idea. The moment somebody wants strictness they have to configure it anyway so they add either include-paths or ignore-paths or both. But it is still sensible to scan all files except ignored paths if include paths is not provided. Same with cache, keep it on by default, let those who want tweak it. If you keep it off people may not turn it on and you dont get to get the reports and make it better. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
One of my intentions in developing the plugin was to have the simplest "getting started": install the plugin, and you're ready to go. At first, the plugin would inspect all classes that are part of the autoload process to look for attributes. This has proven quite expensive with large vendor directories e.g. Symfony framework, or the Google SDK. To speed things up I added a cache system, but it comes with its own challenges: keep the cache fresh and correct.
Since the usage of attributes is usually in the business logic, and not so much in the vendor packages, I think it would be a better idea to require the paths to inspect from the user, even if it means requiring configuration. If there are a few files to inspect, we might not require a cache to run by default, that could be made optional.
Basically, the idea would be the opposite of what we're doing today:
composer.json
.Wdyt?
Beta Was this translation helpful? Give feedback.
All reactions