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. We want to tackle the following components. To be able to grasp the overall plan, each of the components are explained in detail here as they are planned to be implemented at any given time. The specifics of each component is to be discussed in the respective meta-issue.

#1704738: [meta] Make Libraries classes implementing LibraryInterface
Libraries 7.x-2.x already supported 3 types of libraries (JS, CSS, PHP). We want to
  1. Support more library types (Autoload, PEAR, ...)
  2. Allow certain libraries to have their own business logic with regards to loading, etc. One example would be supporting jQuery.noConflict() in order to allow loading multiple versions of jQuery on one page.

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.

#773508: [meta] Provide a central repository of library information (i.e.
We want to provide a central repository of the Library classes described above. We need a canonical list of library machine names each of which maps to a certain Library class, which is canonically developed/maintained. The current proposal is to develop a site, which acts as that repository. How the code for the class will be maintained will have to be discussed. Given a library machine name, Libraries API will then query that central repository to obtain the Library class. How this can happen safely and conveniently will also have to be discussed. There was also an alternate idea to commit the Library classes directly to the Libraries API module. That would make things easier for users, but comes with an increased maintenance effort.
#542940: [meta] Support for downloading libraries via Composer
Since, which uses Composer, seems to be the PHP package archive, we want to download all libraries, including JS and CSS libraries from there. That means that if a certain library does not have a composer.json file, and/or a package on, 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.

All issues of the 8.x-3.x branch


tstoeckler’s picture

Issue summary:View changes

Add link to issue list.

heyrocker’s picture

Issue summary:View changes
tstoeckler’s picture

Version:7.x-3.x-dev» 8.x-3.x-dev

Changing version to 8.x-3.x

tstoeckler’s picture

Title:[master] Libraries API 7.x-3.x» [master] Libraries API 8.x-3.x

Also updating title now (fail...). I had updated the issue summary before.

tstoeckler’s picture

Issue summary:View changes

Updating for 7.x-3.x -> 8.x-3.x

rjacobs’s picture

I just wanted to see if there have been any updates on any of this. From what I can see there have not been any new (meta) notes on the D8 branch since 2012. I think it would be especially interesting to know if #1704738: [meta] Make Libraries classes implementing LibraryInterface is still in the works as that would have a big impact on how other developers make use of the API (and it would be good to plan accordingly). There have not been any updates on that issue since 2012 either.