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

Comments

catch created an issue. See original summary.

alexpott’s picture

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.

I think this would be really smart. In fact I think it'd be awesome to add it as a composer plugin that used information from composer.json rather than building it into our own special autoloader. The plugin could look in the the extra info for deprecated dependencies and then if there are some prepend an autoloader that triggers a silenced deprecation if a class from that package is requested.

It could also work out if another package has the same dependency which is not deprecated and then not trigger the deprecations.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.