# 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
https://www.drupal.org/project/libraries
# Where is the code?
http://cgit.drupalcode.org/libraries/log/?h=8.x-3.x
# Estimated completion date
Unknown.
# Dependencies
N/A
# Who's doing the port?
@tstoeckler and @rjacobs
# What help do they need?
Unknown
# 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)
Comments
Comment #2
FrancewhoaComment #3
Kristen PolChanging to correct status.
Comment #4
rjacobs CreditAttribution: rjacobs commentedI 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.
Comment #5
rjacobs CreditAttribution: rjacobs commentedOk, 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.
Comment #6
rjacobs CreditAttribution: rjacobs commentedHa! 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.
Comment #7
joyceg CreditAttribution: joyceg commentedI 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?
Comment #8
anuditverma CreditAttribution: anuditverma commentedHi, 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.
Comment #9
SKAUGHTComment #10
SKAUGHTComment #11
netgeek123 CreditAttribution: netgeek123 commentedAny plans to bring this to Drupal 8?
Comment #12
mmjvb CreditAttribution: mmjvb as a volunteer commented