Problem
- Some external libraries are contained in specific core modules, which prevents contrib from using them without having to depend on the respective core module.
Details
Previously,
core.libraries.yml
did not exist, so e.g., System module registering CKEditor module's library made little to no sense.By introducing the capability for the Drupal core base system itself to register libraries, the new world order is this:
- All external libraries supplied by Drupal core are placed into
/core/assets/vendor
. - All of those libraries are registered by
core.libraries.yml
. - Placing an external library into a core module is discouraged and requires a very sound, solid, and sophisticated reasoning.
- All external libraries supplied by Drupal core are placed into
Here is why:
- A contributed or custom module that would like to use the existing bundled library but does not like the usage/implementation of the core module, would (1) either have to needlessly depend on the core module to get the library registered or (2) re-register the library from scratch on its own (which breaks dependencies of other modules, since the library owner/provider would no longer be "core").
- Re-registering a core library in a contrib/custom module would be close to impossible to manage with regard to the declared library version. Drupal core might ship with an updated version, but that will not be reflected in the contrib module's declaration unless it is updated accordingly.
In short, this is required for e.g. Wysiwyg module to use the CKEditor library bundled with core, without having to depend on the ckeditor.module in core. Same for other libraries/modules/use-cases.
Task
- Move the picturefill.js library from Picture module into core.
- Move the jquery.joyride library from Tour module into core.