Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 294537

Trigger deprecation notifications for replaced Vendor classes

$
0
0

Problem/Motivation

Sometime we replace an implementation of a class in vendor with one in core, either because we've had to fork it from a dependency we're still planning to use, or because we've moved away from that dependency altogether.

In these cases, we want to inform people to use the new class in core, but because we don't control the code in the vendor class, we can't easily trigger a deprecation notice. Also the class in vendor hasn't been deprecated by the dependency, it's just Drupal core that wants to deprecate its use.

Currently the only way we have to inform people of this is:

1. Change records
2. Static analysis via Drupal check/rector

But it would be useful to be able to trigger deprecation notices during tests too.

Proposed resolution

A brute force way to do this is to class_alias() a class in the core namespace to take over the vendor one, and then add @trigger_error('...', E_USER_DEPRECATED) in there. However this has the potential to add quite a lot of cruft and duplicated logic, just to add a @trigger_error().

Another way might be to add deprecation capability to the autoloader during tests, so that the autoloader itself triggers deprecation notices based on a list of classes.

We could also decide to rely on static analysis for this after all, but in that case should document it in the deprecation policy: https://www.drupal.org/core/deprecation

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Viewing all articles
Browse latest Browse all 294537

Trending Articles