Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.There have been some big changes in 8.x-3.x, not just to the module's architecture and core integrations, but also to the procedural management of library data. Given that the module is such a popular/important API provider we need to start exposing some of these new concepts and structures to other module developers as soon as possible. I think that some maintainers who have historically required Libraries API have already moved forward with their D8 porting efforts by either dropping libraries API (which is not good for interoperability across contrib) or by only partially leveraging it with ad hoc workarounds in their own code (leading to inconsistent duplication). Now that most of the larger architectural decisions seem to be firming-up I'm hopeful that it's not too early to start focusing on what's needed before committing to the first alpha tag.
I suppose part of this involves discussing exactly what we would be committing to under the "alpha" status (I think a lot of projects have different ideas around this) but mostly I think we just need a place to link and track individual issues that are loosely considered "alpha-blockers".
We of course have #1704734: [master] Libraries API 8.x-3.x, but I think that might be a bit too high-level for this planning task. Results and notable updates from here could be announced there however.
Also marking #1704734: [master] Libraries API 8.x-3.x a parent.
Comments
Comment #2
rjacobs CreditAttribution: rjacobs commentedSo it looks like #2774313: Validate library dependencies when extensions are installed and more gracefully deal with library-specific errors at runtime is fairly fundamental.
Also, we should probably wind-down #2770983: Implement canonical repository of library definitions (iterative steps toward libraries.drupal.org). For that one we definitely don't need to have a registry hosted in any particular place (libraries.drupal.org) we just need it running somewhere remotely and the related integration considerations stable. Maybe we can spin-off a follow-up related specifically to the to libraries.drupal.org hosting stuff which would allow us to close #2770983 prior to alpha.
Comment #3
tstoecklerDamn, had a detailed comment written for this, but somehow lost it. Will try to write it up again sometime in the next couple of days.
In any case, thank you for opening this! We're getting close, I think... (to an alpha at least)
Comment #4
rjacobs CreditAttribution: rjacobs commentedThese two issues may relate to some fundamental config schema changes, which I suppose should also be somewhat stable before an alpha... for consideration, maybe not hard alpha-blockers though.
#2825940: Remove LibrariesServiceProvider madness
#2818689: Add ability to scan multiple stream wrappers when locting library source
Comment #5
tstoecklerOk, finally coming back to this at DrupalCamp Munich.
So I think the baseline for an alpha should be that the new API works for at least some use-case however small that may be. So since we now support remote library loading and we can automatically fetch the definitions, we have somewhat achieved this to an extent: A module can put a
library_dependencies: [foo]in their info.yml file and then - assuming that the remote registry has a definition for foo and that foo is remotely loadable - they can simply declare libraries/foo a dependency of their JavaScript in their libraries.yml and it just works (tm).The things that currently break are if the library (definition) is not actually available. That is what I think we should at the very least fix. We should provide proper error messages if something is wrong, but we should never fatal. So I think in terms of issues #2774313: Validate library dependencies when extensions are installed and more gracefully deal with library-specific errors at runtime would be one step of that. I guess there might be other problems as well.
And then there might be other issues that I would be open to add as alpha blockers.
You suggested #2818689: Add ability to scan multiple stream wrappers when locting library source which would actually allow (in a follow-up, I guess) to implement proper support for multiple library locations (/libraries vs. /sites/all/libraries vs. /..). That would be really nice to have, because we otherwise we really only properly support remote libraries, IMO.
#2825940: Remove LibrariesServiceProvider madness is kind of nice to have IMO, but it's pretty much done, so I don't think that will be holding us up either way.
Comment #6
rjacobs CreditAttribution: rjacobs commentedI'll go ahead and add #2825940: Remove LibrariesServiceProvider madness and #2818689: Add ability to scan multiple stream wrappers when locting library source to the "official" list based on #5. I also opened a related small follow-up to those: #2839977: Add hook_update_n for conf schema changes (before alpha) (which I think may be justified by the already very high usage of the dev branch).
Comment #7
rjacobs CreditAttribution: rjacobs commentedAgreed. I've started working on this in #2774313: Validate library dependencies when extensions are installed and more gracefully deal with library-specific errors at runtime. In hindsight I suppose I should have opened-up another issue (there are a lot of moving parts now in #2774313), but it seemed like the most relevant place to start the conversation. My goal is to implement enough error handling there that we can bump-down the priority from critical and remove it from the alpha-blockers. That could be the last missing piece for an alpha release.
Comment #8
Chris Matthews CreditAttribution: Chris Matthews commented8.x-3.0-alpha1 was released in January 2018. Does this issue need to be closed or changed to a discussion re: an alpha2 -or- beta1 release?