Closed staabm closed 2 years ago
No idea what you're talking about, can you provide an example?
a project which references class from a different package in a .neon file like e.g.
services:
-
class: Symplify\PHPStanRules\CognitiveComplexity\Rules\FunctionLikeCognitiveComplexityRule
tags: [phpstan.rules.rule]
arguments:
maxMethodCognitiveComplexity: 8
would be interessted whether the class Symplify\PHPStanRules\CognitiveComplexity\Rules\FunctionLikeCognitiveComplexityRule
is considered deprecated and might go away in a future release (or a alternative should be used).
when such file is only referenced in .neon files, noone see a error otherwise anywhere.
I know that people tend to do this and PHPStan more or less supports it, but the package author isn't free to change constructor arguments and add/remove/rename the classes. I'm careful with this in PHPStan itself but I don't want to ask this of other authors.
The longterm solution isn't to include rules in custom configs like this but instead take advantage of error identifiers (https://github.com/phpstan/phpstan/issues/3065) to include/exclude rules in config.
Right now your only correct option is to use the whole package and ignore errors based on regexes in ignoreErrors
.
Another option is to contribute/ask for separate config parameter that would be used in conditionalTags
section like this:
parameters:
symplify:
functionLikeCognitiveComplexity: true
parametersSchema:
symplify:
structure([
functionLikeCognitiveComplexity: bool()
])
conditionalTags:
Symplify\PHPStanRules\CognitiveComplexity\Rules\FunctionLikeCognitiveComplexityRule:
phpstan.rules.rule: %symplify.functionLikeCognitiveComplexity%
services:
-
class: Symplify\PHPStanRules\CognitiveComplexity\Rules\FunctionLikeCognitiveComplexityRule
arguments:
maxMethodCognitiveComplexity: 8
(FYI I'd welcome these parameters in phpstan-strict-rules too.)
That way you'd be able to turn off this rule with these lines in your phpstan.neon:
parameters:
symplify:
functionLikeCognitiveComplexity: false
Another nice benefit is that you'd be able to use phpstan/extension-installer even if you don't want to use everyhing a package offers.
But if you include rule classes in your config like this I think it's right to expect it can break from time to time.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
would it be possible to have a new Rule which reports errors when nette-config files reference classes which are
@deprecated
.this would help to provide a smoother migration path for packages which distribute phpstan extensions via .neon files.
see also https://github.com/symplify/symplify/issues/4169 for a related problems discussion about BC breaking changes in phpstan context.