This is a master issue to track progress of the 8.x-3.x release of Libraries API. This will be a completely revamped release. As in Drupal 7 Libraries API remains an important requirement for D8 sites and overall CX. Though Drupal 8 core has introduced improved library management tools (libraries.yml and unified library loading) it still does not offer a solution for handling external library dependencies that may be shared across multiple extensions. As a result this remains the primary problem space for the Libraries API module.
Overall Architectural Considerations
- Currently the foundational work to implement a decoupled architecture that will work for D8 is being addressed here. This is a major rewrite of all subsystems provided by the module, and serves as a base for all other hands-on porting efforts and development work. Anyone interested in low-level architectural considerations for the module and its own extensibility will want to get involved in this issue.
- A remote central repository of library definitions managed by/for the Drupal community (see next section - #773508).
- Leveraging definition data from existing cloud services (cdnjs.com).
- A hybrid approach that allows use of remote definitions with the ability for local overrides.
Asset Libraries and Core Library Definitions
Improved integration with core's asset library handling has been a topic of discussion for some time (e.g.). Now that assets (CSS and JS) can no longer be loaded reliably outside of a core library definition (typically via "#attached" on a render array) we need a new mechanism to dynamically declare core library definitions on behalf of dependent extensions. This shifts the burden of loading assets to core (which it does well natively) and allows Libraries API to focus on the management of library definitions, sub-dependecies, etc. This should prove to be a much cleaner approach but still presents several unique implementation challenges.
Work to ensure that core offers the appropriate APIs to accommodate this approach is addressed in(among others), and initial design work for this concept is discussed in .
The extent to which Libraries API can (or should) be a solution for non-asset libraries (beyond JS and CSS assets) is an open topic. If this continues to be a priority (do we need a simple y/n issue for that?) the following issues are potentially relevant:
- Libraries 7.x-2.x already supported 3 types of libraries (JS, CSS, PHP). We want to
- Support more library types (Autoload, PEAR, ...)
- Allow certain libraries to have their own business logic with regards to loading, etc.
Both of these points can be easily achieved in an object-oriented fashion. Since (a) we gain automatic autoloading of the Library information files and (b) Drupal 8 is moving towards an object-oriented design, this seems like a natural fit. We will organize both our own files, as well as the Library classes in accordance with PSR-0.
- Since http://packagist.org/, which uses Composer, seems to be the PHP package archive, we want to download all libraries (possibly even including JS and CSS libraries) from there. That means that if a certain library does not have a
composer.jsonfile, and/or a package on http://packagist.org/, this needs to added "upstream" first, in order for Libraries API to support it. Each Library class will include a method called "getComposerURL", which Libraries API will use to download the library.