phpstan / phpstan-nette

Nette Framework class reflection extension for PHPStan & framework-specific rules
MIT License
100 stars 35 forks source link

report deprecation errors, when a nette file references a `@deprecated` class #103

Closed staabm closed 2 years ago

staabm commented 2 years ago

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.

ondrejmirtes commented 2 years ago

No idea what you're talking about, can you provide an example?

staabm commented 2 years ago

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.

ondrejmirtes commented 2 years ago

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.

github-actions[bot] commented 2 years ago

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.