Tracking deprecations

[xificurk]

One of the popular strategies for marking deprecated code in libraries is to use @trigger_error('...', E_USER_DEPRECATED) call, see:

• https://github.com/doctrine/deprecations
• https://github.com/symfony/deprecation-contracts

The main advantage and also its main disadvantage is that this method is by default side-effect free. You need to have custom error handler to collect and track usage of the deprecated code.

For PHPUnit there is symfony/phpunit-bridge that has quite an extensive feature set for detecting and tracking the deprecations ( https://symfony.com/doc/current/components/phpunit_bridge.html ).

I would like to add at least some basic support for detecting and tracking these deprecations to Nette Tester. Before I start working on any PRs, I would like to discuss, if this even is something that would be accepted. And if yes, what kind of support should I aim for in the first iteration?

[dg]

I never understood the point of it. Can you give a specific example of what problem it solves?

[xificurk]

Are you asking about tracking the usage of deprecated code? As a user/consumer of the 3rd party package, I would like my CI with Nette Tester to fail, if I use some deprecated API.

[dg]

I am asking about @trigger_error().

[xificurk]

The main pro-argument I've seen is what I've mentioned - it's side-effect free by default, i.e. the deprecation tracking is opt-in.

But that's not really a problem I want to discuss here... The bottom line is that this strategy is used by various 3rd party packages and it is quite popular. As a user/consumer of those packages and user of Nette Tester, I would like to have way how to detect those deprecations.

[dg]

And what do you mean by „detect those deprecations“? Something like a $scream from your second pull-request?

[xificurk]

Yes, something like that. What exactly "detect" means is one of the things I wanted to discuss.

Catching these deprecation warnings requires a custom error handler, what happens next is an open question. Should the error be simply unmuted and bubble up? Should it be only logged and reported as a soft error at the end of tester run? Should this be configurable? Should there be some kind of support for ignoring specific deprecations? Does it make sense to have various categories for deprecations from direct / indirect calls along the lines of phpunit symfony bridge?

Currently, it's not even very feasible to implement this reliably outside of Nette Tester, because Assert::error() registers own error handler, which does not pass the not handled errors up to the previously registered error handler.