Contrib.social

Implement core management of 3rd-party FE libraries

Open on Drupal.org →
Created on 26 April 2017, about 7 years ago
Updated 4 June 2024, 21 days ago

Problem/Motivation

During the Managing Drupal sites with Composer BoF at DrupalCon Baltimore 2017, the topic of contributed module front-end library management came up.

Here's the current problem:

  • Webform (and other similar contrib projects) requires a 3rd party front-end library.
  • Modules can't rely upon libraries being available inside [drupal-docroot]/vendor/[library/here], because the project vendor directory isn't guaranteed to be in the docroot.
  • Current practices seem to indicate that a libraries folder in the docroot is the best place for 3rd party front-end libraries.
  • It's hard to get contributed module dependencies to be installed to [drupal-docroot]/libraries/[library/here] instead of the vendor directory. Especially if the library doesn't care about Drupal and doesn't have a custom type of drupal-library

There are ways to hack around this:

  • Add a custom and project-specific repository for every 3rd party library in your composer.json file.
  • Use the composer-installers-extender library to allow the specification of the install path per-library.
  • Ditch Composer and just download and commit all the 3rd party libraries into the [drupal-docroot]/libraries folder.

Proposed resolution

It would be really helpful if Drupal core could enable contributed modules to do things like specify a specific path into which a 3rd party dependency will be placed.

One solution we discussed would be adding code that responded to a Composer hook and moved a downloaded dependency into a specified path (which could be indicated via the project's composer.json file).

So a contributed module maintainer (e.g. Webform, Font Awesome Iconpicker, etc.) would add something like (pseudocode):

    "extra": {
        "drupal-install-library-path": "libraries"
    }

And then when you composer require that contributed module, something in Drupal core's composer configuration would pick up that path and place the libraries for the 3rd party module into the specified path.

This is totally open to change (in terms of implementation), but the general idea is: everyone is solving this problem in a different way, and it would be nice if core could provide an official mechanism for doing this 'the Composer way'.

Or, at a minimum, we should document a recommended solution.

Remaining tasks

  • Choose an approach (custom Composer hook? Add another library to help? Use/recommend Robo?)
  • Implement the approach (this part's easy, right?)
  • Document / announce the change so Contrib modules and themes can use this new approach

User interface changes

N/A

API changes

There may be some additional API functionality, but probably not.

Data model changes

N/A

✨ Feature request
Status

Active

Version

11.0 🔥

Component
Other  →

Last updated about 10 hours ago

Created by

🇺🇸United States geerlingguy

Live updates comments and jobs are added and updated live.
  • JavaScript

    Affects the content, performance, or handling of Javascript.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024