Closed (fixed)
Project:
Drupal core
Version:
main
Component:
other
Priority:
Normal
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
30 Mar 2018 at 06:29 UTC
Updated:
29 Mar 2026 at 05:20 UTC
Jump to comment: Most recent
Problem/Motivation
Drupal core relies on external dependencies. Sometimes we no longer need a specific dependency for core purposes. The reason we cannot remove the dependencies when they become obsolete for the core itself is that contributed projects or customizations might still depend on those. Instead, we need to have a process to mark them as deprecated so that they could be removed in the next major release.
We should take into account various aspects of the problem since we have various kinds of dependencies. Not all of our dependencies are downloaded through package management systems like composer or npm. We have dependencies in both, PHP and JavaScript and they are being used differently. Not all of the dependencies are exposed as services or asset libraries.
Proposed resolution
Add an item to change records for adding a change record when an unused dependency is added.
-- original proposal ---
- Dependencies not exposed as services or asset libraries and loaded through a package manager can be removed. If a contributed project or custom module depends on that, they should have documented their dependency to their package manager configuration.
- Dependencies exposed as services or asset libraries (loaded through a package manager or not) cannot be removed but will be marked as deprecated. Provide a new feature that allows marking asset libraries and services as deprecated once they are no longer needed which would trigger a deprecation error if used.
Comments
Comment #2
cilefen commentedA use-case: #2901363: Move easyrdf/easyrdf to require-dev
Comment #3
catchA change notice seems sufficient for something like this. We do not need to throw a deprecation notice for every single change, just ensure that modules are able to update in a forwards-compatible way during the 8.x cycle (in this case by specifying the dependency themselves).
Comment #4
andypostAnother use-case #2951857: Update classList.js to 1.2.20180112 if we deprecate then should be update or not?
Comment #7
catchFor libraries the obvious place to trigger a deprecation error would be Drupal\Core\Asset\LibraryDiscovery::getLibraryByName() - by adding a 'deprecated' key to library definitions - maybe with a deprecation message as the value?
Comment #8
wim leers#7: @mikelutz created #3064017: Create a means to mark an asset library as deprecated in a *.libraries.yml file for this, which is now close to RTBC.
What's en example of this?
Comment #9
lauriii@Wim Leers I can't remember if I had a specific case in my mind, or if it was a hypothetical scenario. I can't find any examples that would fit this so I went forward and removed that from the issue summary.
Comment #10
catchFor asset libraries #3067251: Deprecate unused jQuery UI components in favour of a suite of contrib modules now has an actionable plan to deprecate the unused jQuery UI components. I don't think we'd need to do that for every core component - in this case we have confirmation that while core doesn't use them, contrib is using at least some. Also the ability to mark libraries as deprecated landed.
#8/#9 that sounds like 'dead code' to me that could simply be removed (even if only in a major) since it's not exposed as an API.
Comment #19
quietone commentedAdding where this can be documented and added some text as a start. Change as you see fit.
Comment #21
quietone commentedI've reread this and I think a better option is to add this to the policy for change records.
Comment #22
quietone commentedBTW, the page the change is made to did not exist when this was first opened. That bring the doc up to current practice.
I've updated credit.
Comment #23
quietone commentedActually, I am going to close this as fixed. This has been stale for 7 years and my prompt 10 months ago didn't engage anyone. And all docs are evolving, so we can tweak it as needed.