2

All I thought Composer takes care of any external library a contrib module requires automatically. I tried installing one, Composer took care of all its dependency modules, but not so much with the external library.

How do I use Composer to install external libraries that any module depends on?

Improve this question
3
  • Modules that have external composer dependencies need to declare that dependency in composer.json, within the module file. If the module is not doing that, you should open up a ticket in the issue queue for the module. In the meantime, you can simply use composer require some/library to manually add the library yourself.
    – Jaypan
    Sep 26, 2018 at 8:21
  • @Jaypan, that surely is correct for Composer packages. JS libraries however make no sense to be defined within composer.json, as they'd require either a wrapper package which almost never is the case, or a custom repository definition, which won't be picked up by the parent project's Composer installation.
    – Mario Steinitz
    Sep 26, 2018 at 9:18
  • The Vendor Stream Wrapper module (dgo.to/vendor_stream_wrapper) can be used for JS libraries.
    – Jaypan
    Sep 26, 2018 at 9:20

2 Answers 2

Reset to default
3

Definitly https://asset-packagist.org/

Minor annoyance is the incosistent naming, depending on the module, you have to use either composer require npm-asset/js-lib or composer require bower-asset/js-lib

Add the settings to composer.json as documented on asset packagist (see Installing to a custom path), and set the drupal-specific installer-path, e.g. something like

"extra": {
    "installer-types": ["bower-asset", "npm-asset"],
    "installer-paths": {
        ....
        "web/libraries/{$name}": ["type:drupal-library", "type:bower-asset", "type:npm-asset"],
        ...
    }
}
Improve this answer
1
3

It is not recommended to installing JavaScript libraries using composer.json, but it is possible.

Note: This repository type has a few limitations and should be avoided whenever possible:

Composer will not update the package unless you change the versionfield.Composer will not update the commit references, so if you use master as reference you will have to delete the package to force an update, and will have to deal with an unstable lock file.

(Composer docs)

If your package is available for download at an external source, e.g. as an archive, you could add it as custom package with type drupal-library to the repositories section of your Drupal project's composer.json, and then require this package accordingly:

"repositories": {
  "drupal": {
    "type": "composer",
    "url": "https://packages.drupal.org/8"
  },
  "mypackage": {
    "type": "package",
    "package": {
      "name": "myvendor/mypackage",
      "version": "1.0.0",
      "type": "drupal-library",
      "dist": {
        "url": "https://example.com/mypackage.zip",
        "type": "zip"
      }
    }
  }
},
"require": {
  ...
  "composer/installers": "^1.2",
  "myvendor/mypackage": "1.0.0"
},
"extra": {
  "installer-paths": {
    "public/core": ["type:drupal-core"],
    "public/libraries/{$name}": ["type:drupal-library"],
    "public/modules/contrib/{$name}": ["type:drupal-module"],
    "public/profiles/contrib/{$name}": ["type:drupal-profile"],
    "public/themes/contrib/{$name}": ["type:drupal-theme"],
    "drush/contrib/{$name}": ["type:drupal-drush"]
  },
  ...
}

Check the Repositories documentation for Composer for more details or other source types.

Improve this answer
4
  • Interesting - I can't recall having seen a recommendation not to put JS libraries in Composer, do you have a reference for that? The fact that the Drupal ecosystem has gone to the trouble of creating a drupal-library package type, which the Drupal Project knows how to install in the right docroot/libraries folder automatically, and is specifically for JS libraries, might suggest otherwise?
    – Clive ♦
    Sep 26, 2018 at 9:39
  • The repo also doesn't need to be publicly available - composer has authentication integrations with github, bitbucket, etc. We use this workflow liberally for default project installations, installation profiles, installing private modules etc
    – Clive ♦
    Sep 26, 2018 at 9:50
  • 1
    Ah ok, yeah, in Symfony/Laravel/etc I can understand that, they have their own opinions on how external assets should be managed. In a Drupal context I don't believe there's a recommendation not to do it, not one that I've come across anyway - the standard installation/management methods facilitate it in a reasonably elegant way
    – Clive ♦
    Sep 26, 2018 at 9:54
  • Well I stand corrected :) Thanks for following up, that's a good thing to know
    – Clive ♦
    Sep 26, 2018 at 10:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.