# Summary

This is an API module for integrating with external libraries.

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.

Additional information is available at #1704734: [master] Libraries API 8.x-3.x.

# Project URL


# Where is the code?


# Estimated completion date


# Dependencies


# Who's doing the port?

@tstoeckler and @rjacobs

# What help do they need?


# D8 roadmap

#1704734: [master] Libraries API 8.x-3.x

# Background and reference information

Using Libraries API 8.x-3.x (as a module-developer) (last updated Jan 2014)


Patrick Storey created an issue. See original summary.

Francewhoa’s picture

Kristen Pol’s picture

Status: Closed (works as designed) » Closed (fixed)

Changing to correct status.

rjacobs’s picture

Status: Closed (fixed) » Closed (duplicate)
Related issues: -#2605194: [libraries] Libraries API

I think "duplicate" is the correct status as this is a dup of an existing contrib_tracker thread for the Libraries API module. Marking this as "fixed" might trick contrib_tracker into thinking that the D8 port for the module is complete, which it is not. The contrib_traker project, and all it's special d.o. logic, should really be referencing the status of the canonical thread for this: #2607762: (Duplicate) Libraries API.

rjacobs’s picture

Title: [libraries] Libraries API » Duplicate - Libraries API
Status: Closed (duplicate) » Closed (cannot reproduce)

Ok, so neither "fixed" or "duplicate" are correct as they both have special meaning to contrib_tracker, which is unfortunately is now referencing this issue in its project calculation logic.

It looks like contrib_tracker will ignore this if we use status "cannot reproduce". I've also altered the title as I think that will detach this thread from the module in favor of #2607762: (Duplicate) Libraries API.

rjacobs’s picture

Title: Duplicate - Libraries API » [libraries] Libraries API
Priority: Normal » Major
Issue summary: View changes
Status: Closed (cannot reproduce) » Needs work

Ha! So apparently that other contrib_tracker issue #2607762: (Duplicate) Libraries API that webchick opened is actually the real duplicate, as it was opened ~1 week after this one. Which could explain why d.o. insists on using this issue when deriving the project porting status despite my efforts above.

So let's just make this thread the official thing. I'm copying over the appropriate status and details from the other thread.

joyceg’s picture

I am interested in taking this project on for GSoC and would like to know if it is possible to have the roadmap completed soon.

The actual requirement is not mentioned here.
Can someone please specify it?

Can a GSoC participant make progress to this release?

anuditverma’s picture

Hi, I'm Anudit Verma, I have been following this discussion for while, followed the community documentation and issues related to it. I learned that when we want to implement these Library API in our custom module (implied we have followed a standard naming convention) we use hook_libraries_info() for any usage of an external library. I also learned that if our module has jQuery file it wouldn't load, as Drupal only loads core libraries.
Also I got to know that there is a possibility to overcome this if we dynamically define libraries via hook_library_info_build or defining them in libraries.yml file. I looked upon the differences of using hook_libraries_info() in 7.X and 8.X versions here to get a better insight of the interoperability.
I want know more about current implementation problems and love to be the part of this discussion in order to take this up a GSoC project.

SKAUGHT’s picture

SKAUGHT’s picture

netgeek123’s picture

Any plans to bring this to Drupal 8?