Add a packages.drupal.org to root composer.json

Looks good to me.

Patch still applies.

After application I did this:

$ composer require drupal/phpunit_example
Using version 1.x-dev for drupal/phpunit_example
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing drupal/examples (dev-1.x 0001f5b)
    Cloning 0001f5b197bb1932b8239fb618b8858765f9af2a

This added phpunit_example as a dependency and gave me this change to composer.json:

         "composer/installers": "^1.0.21",
-        "wikimedia/composer-merge-plugin": "~1.3"
+        "wikimedia/composer-merge-plugin": "~1.3",
+        "drupal/phpunit_example": "1.x-dev"
     },

...but Composer then ended up satisfying this dependency by adding the whole drupal/examples project. I think this is the right way to do it.

That fail looks actually related? Queuing a retest.

I can't do it now, but somebody needs to run composer update --lock after this patch has been applied, and include the result.

Here you go :)

+1 on #9.

And RTBC on #10 except for one thing:

Let's add an explanation to extra->_readme in composer.json so it says "This file specifies the packages.drupal.org repository. You can read more about this repository here: https://www.drupal.org/node/2718229"

Sigh. Patch doesn't apply.

$ git apply 2758737-15.patch 
error: patch failed: composer.lock:4
error: composer.lock: patch does not apply

You can add the drupal endpoint with $ composer config repositories.drupal composer https://packages.drupal.org/8 as #2 already said.

Using the method from this issue a couple things happen that I am not sure if that is good/recommended:

1. Core is 'hacked'. Anytime you add a module with $ composer require ... the top composer.json will be changed.
2. All modules are downloaded to the folder /modules not /modules/contrib . This can be difficult to manage when you add custom modules.
3. All modules that are managed with composer are *also* included in git. Best practise is that a module is either managed in git (all code of the module) or only by an entry in composer.json (as metadata)

Compared to https://github.com/drupal-composer/drupal-project this method is less sophisticated.
But it does work well!

Core is 'hacked'. Anytime you add a module with $ composer require ... the top composer.json will be changed.

Core doesn't own the root composer.json, the project does. This file is meant to be changed, just like htaccess for example.

All modules are downloaded to the folder /modules not /modules/contrib . This can be difficult to manage when you add custom modules.

Not in 8.3.x:

            "modules/contrib/{$name}": ["type:drupal-module"],
            "profiles/contrib/{$name}": ["type:drupal-profile"],
            "themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/contrib/{$name}": ["type:drupal-drush"]

Thanks Bojanz. Missed those changes in 8.3.x !
Regarding to the ownership of the root composer.json > did not know it was meant to be changed.

Rerolled against 8.x-3.x

2 things are different then #15
1. hash + content-hash (sure)
2. no further changes in composer.lock

There's some ambiguity about the composer facade respecting the 'type' property of Drupal projects: #2802009: Provide support for libraries and other non-drupal extensions (modules, themes etc)

Specifically Coder, which is a Drupal project but also a library and not a module. We want to include it as a dev requirement for core: #2744463: Add phpcs, coder 8.2.8 as --dev requirements for drupal/core

I just added the facade as per #2 composer config repositories.drupal composer https://packages.drupal.org/8

And then added Coder: composer require --dev drupal/coder 8.2.8

..and everything ended up where it should, but I'm not sure that isn't by accident, since #2802009: Provide support for libraries and other non-drupal extensions (modules, themes etc) is still open.

I think version number drupal/coder is not a concern anymore, it has been added as dev-dependency in #2744463: Add phpcs, coder 8.2.8 as --dev requirements for drupal/core.

Okay, let's go.

We def wants this in 8.3.x as well, should be completely non-disruptive.

Awesome, let's get this in.

Edit: Ahh, damn, @bojanz was quicker ;-)

So eventually, as per #24, we'll need to change the requirement to drupal/coder 2.*.0, but not before the issue of d.o projects being libraries is resolved in #2802009: Provide support for libraries and other non-drupal extensions (modules, themes etc) and elsewhere.

Committed 475e305 and pushed to 8.4.x. Thanks!

We need a new patch for 8.3.x

The hash key and the date format change in composer.lock because this is composer update --lock with the current version of composer.

Made a follow-up: #2851279: Update version requirements for drupal/coder to best practices

Is there an issue open for updating the composer merge plugin config to parse contrib module dependencies?

@cilefen
There is an old issue, but I don't remember if it was still open, cause it doesn't make a lot of sense. If you need to run Composer anyway, then use it to download the whole module.

I found it.

Patch is green.

Committed 1d1daa8 and pushed to 8.3.x. Thanks!

Committed 1d1daa8 and pushed to 8.3.x. Thanks!