Updated "composer/installers" version to support custom path modules

[miteshmap]

composer/installer latest tag is - v1.0.23 but updating it to master for this
composer/installers#269

[webflo]

I don't get why we need this nor where these new types are documented on drupal.org. Its already possible to override the install location for each package. You just have to add the package name and location before the generic path.

diff --git a/composer.json b/composer.json
index d5b7ee3..49cbd0e 100644
--- a/composer.json
+++ b/composer.json
@@ -43,6 +43,7 @@
     },
     "extra": {
         "installer-paths": {
+            "web/modules/custom/{$name}": ["drupal/devel", "drupal/pathauto"],
             "web/core": ["type:drupal-core"],
             "web/modules/contrib/{$name}": ["type:drupal-module"],
             "web/profiles/contrib/{$name}": ["type:drupal-profile"],

[miteshmap]

Thank you @webflo for your input, the new type is defined on composer/installers
The update needed in reference to add custom modules to your site at a specific location by default. as per the drupal standard we place custom modules to "modules/custom", So by defining the type for that, we allow developers to place their custom modules to "web/modules/custom/{$name}": ["type:drupal-custom-module"], this location.

Many large sites have 20 - 25 custom modules, which should be pulled from a gitlab / github or any custom vcs location. so we allow them to simply use type instead of defining each module like,
"web/modules/custom/{$name}": ["drupal/devel", "drupal/pathauto"],

[bojanz]

I think it's a reasonable shortcut, and miteshmap already got the change added to composer/installers

[miteshmap]

Thanks @bojanz, Indeed it's a good shortcut. 👍

[jibran]

Does this means I have to create a separate repos for all my custom modules & themes and add "type": "vcs" & url: in my main composer.json under repositories to pull them in and mention "type": "drupal-custom-module", or "type": "drupal-custom-theme", in all my custom modules & themes composer files?

[derhasi]

We went with "web/modules/{$vendor}/{$name}": ["type:drupal-module"], in some projects. This way we ended up with contrib in web/modules/drupal, and some team/client specific modules in web/modules/[clientname]. And we could still place custom modules in web/modules/custom for project specific modules.

[webflo]

Updated composer/installers in 7e329fa

[zaporylie]

For the record - You can use "vendor:your-company" syntax to install package for specified vendor in predefined location.

Example:

"extra": {
    "installer-paths": {
      "drupal/modules/mycompany/{$name}/": ["vendor:mycompany"],
      "drupal/modules/contrib/{$name}/": ["type:drupal-module"],
      "drupal/themes/contrib/{$name}/": ["type:drupal-theme"],
    },

[allella]

I inherited a D8 project and 15 out of the 30 contrib modules don't have a composer.json with a "type": "drupal-module".

I asked the entityqueue to add a composer.json and they agreed since the composer-installer types are well supported.

I was about to reach out to other contrib modules to do the same. However, I decided to confirm that projects without a composer.json type end up in /vendor. That doesn't seem to be the case because I installed better_exposed_filters and it went to web/modules/contrib/.

Is drupal-composer/drupal-project smart enough to move contrib packages out of /vendor and into web/modules/contrib/ even if they don't have a composer.json with a "type": "drupal-module"?

[allella]

I see the better_exposed_filters maintainer mentioned the Drupal Composer endpoint will create a composer.json for a module based its .info.yaml when one doesn't exist.

I see composer.lock does define a "type": "drupal-module" for modules with no composer.json so I'm now assuming the endpoint is giving it that info and that it's not some drupal-composer/drupal-project magic.

Hoping someone here can confirm if that's what's happening so I can better explain to the maintainers as I'm asking them to create a composer.json with a type: drupal-module.

[zaporylie]

There's absolutely no need to create composer.json file on per-module basis. If composer.json is missing, d.o composer repository will figure out defaults from .info/.info.yml file.
Some modules may still want to create custom composer.json, especially if module requires a 3rd party library.