support deprecation of external classes/a vendor package

[staabm]

this rules - as is - support phasing out deprecated functinality which was marked as @deprecated beforehand (which implies that I rather own the code and can mark it deprecated, or I agree with the deprecations of a external person and follow their judgment).

it would be great if phpstan-deprecation-rules could support more advanced use-cases like phasing out a dependency/package.

lets say we want to soft-migrate a existing codebase with a legacy http client to a more modern http client.
that means we want to make sure, new code which gets implemented should use the new client.
existing code-sites should be reported by phpstan as usage of deprecated functionality.

both - the new and the old http client - are 3rd party libraries and therefore we don't have control over annotating the sources.

I guess this could work with some kind of composer-package-name based deprecation rules, or mabye php namespace based ones.

[ondrejmirtes]

You can solve this just with stub files: https://phpstan.org/user-guide/stub-files

Create a stub file that looks like this and you're set:

/** @deprecated */
class ThirdPartyClass {}

[staabm]

cool thx for the inspiration. is it possible to somehow declare a whole php namespace as @deprecated like that?

[vv12131415]

@ondrejmirtes is it done on purpose? I would like to check deprecation without stub files

[github-actions]

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.