Add a config option to ignore self-deprecations

[VincentLanglet]

When exposing a library, you need to respect semantic versioning and avoid BC-break.

Let's say you have some code

class Foo
{
     /** @deprecated */
     protected $foo;

     private $newFoo;

     public getFoo():
     {
          return $this->foo ?? $this->newFoo;
     }
}

An error is reported because $this->foo; is used but changing this/removing it would be a BC break.

But the phpstan-deprecation-rules would still be useful to detect when I use a deprecated method from another library.

Is it possible to add an option in order to

• Turn off errors if the deprecated Method/Interface/Property/Class/... is from my project
• Keep the erros if the deprecated Method/Interface/Property/Class/... is coming from a vendor

?

[ondrejmirtes]

This should already work because accessing something deprecated from deprecated scope isn't reported.

[VincentLanglet]

This should already work because accessing something deprecated from deprecated scope isn't reported.

My bad, I made a mistake in my example.

Indeed when the method is deprecated there is no issues.
But when the method is not deprecated but do things like

     public getFoo():
     {
          if ($this->foo) {
              trigger_deprecation(...);
              return $this->foo;
          }

          return $this->newFoo;
     }

and will be changed to

     public getFoo():
     {
          return $this->newFoo;
     }

in next major, we have the phpstan error. (And we have a lot of code like this in the library)

[VincentLanglet]

I started to think that maybe the notion of "self-deprecation" wasn't something easy for PHPStan.
In this case ignoring deprecation per namespace could be easier with a config like:

ignoreNamespace:
    - 'App\NamespaceToIgnore'
    - 'AnotherNamespace`

But I think it could be ignored by something like

ignoreErrors:
        -
            message: '#deprecated .* App\\NamespaceToIgnore#'
            path: .

Does this feature would worth an option or do you think the regex-solution is enough ?
Also if you're in favor of the regex @ondrejmirtes,

• Do you think an universal regex could/should be added to the doc ?
• Should we write tests about this regex to be sure all the errors messages respect this regex ?

[jdevinemt]

I think the proposed functionality of the original post would be very helpful. When working on an application, not a library, it can be helpful to mark classes/methods/etc. as deprecated to remind yourself and other developers not to use something anymore and either use or develop newer functionality. It may not be possible to fully remove the deprecated item for quite some time depending on various circumstances.

Currently, there is a way to say "ignore rules regarding the use of deprecated items in this specific scope" via the DeprecatedScopeResolver interface. However, there is not a way to say "ignore rules regarding the use of these specific deprecated items".

Personally, I won't be able to use this extension until that functionality is available because I use the @deprecated tag to mark so many legacy classes to remind myself that there is a better alternative, and they will eventually be removed.

The implementation could be similar to DeprecatedScopeResolver, but instead of being provided the scope, it would be provided something like the node of the class/function/etc. in question. Maybe there is no good universal object to be used for this argument though. I'm not very familiar with PHPStan internals yet.

Say the class is called DeprecatedItemResolver, a method isItemDeprecated() would be used to control whether a class/method/property/etc. in question should be considered deprecated. This would require all the deprecation rules to be updated to call this method to determine if something is deprecated, which would probably be quite the undertaking.

I understand if this is not feasible. But it would be a really nice feature to have.