[Packaging broken!] Composer v2.2 prompts to authorize another plugin when stability=dev

There's currently no test at all for any --stability= parameter, only the default (which in our case seems to be stable https://getcomposer.org/doc/articles/versions.md#stabilities) is tested.

So that should be/is most probable the reason our tests didn't pick up on this one.

If we're wanting to test all stability options (5), it would IMHO require running the full test \Drupal\BuildTests\Composer\Template\ComposerProjectTemplatesTest::testTemplateCreateProject() four more times for both projects drupal/recommended-project and drupal/legacy-project. So 8x more in total.

Since a single run of \Drupal\BuildTests\Composer\Template\ComposerProjectTemplatesTest::testTemplateCreateProject() currently takes around 19 seconds, that would end up with an extra test time of 4 *19 sec = 76 seconds.

Personally I think we can get away with only adding testing the dev stability, but I've been wrong before (many, many times actually...).

Besides the above, could D10.0 be the time to drop support for drupal/legacy-project which seems to be D8 centred?

Leaving all of the above ramblings for Bigger Brains to decide over.

I also think just testing dev is enough for now as it should cover this specific case and it doesn't seem worth the DrupalCI time to test the stabilities in between - we can always revisit later.

Re dropping support for drupal/legacy-project it's always worth opening an issue if you think it is worth discussing.

Thanks @longwave

Re dropping support for drupal/legacy-project it's always worth opening an issue if you think it is worth discussing.

Per usual, @alexpott is already on the case in the just linked related issue #3294241: Remove drupal/legacy-project as a starting point for Drupal 10

I created #3294241: Remove drupal/legacy-project as a starting point for Drupal 10

Little lost on how to test this.

The plugin-allow for dealerdirect/phpcodesniffer-composer-installer comes from drupal/coder which is in the Metapackage drupal/core-dev.

In a local attempt I swapped out the require-dev in the SUT's composer.json with the actual dependencies in drupal/coder's require section.

However this doesn't seem to actually install drupal/coder so the prompt to authorize the plugin dealerdirect/phpcodesniffer-composer-installer is never triggered.

Time for Bigger Brains to step in to decide if a test is needed in the first place (probably yes?) and how to actually test this, and how to handle the possibility that a dependency of a dependency of a [snipped-for-sanity] needs to allow a plugin.

Maybe we should check if a sub-set of allowed plugins in the root composer.json is present in both templates?

I think we can live without a test. I think there is a question about whether we need to fix this or let people answer the question that composer asks. That said I don't think there is any harm in trusting this plugin and doing this does reduce noise.

This change seems sensible. Looks like we need different versions for the 10.x branches, though.

D10.0.x patch created (should apply to 10.1.x)

The changes look good to me, and should resolve issues I've seen locally when committing core patches (where I run composer install, and yarn install after applying a patch, before running the commit which executes phpstan and yarn spellcheck).

Manually tested with a test project and local path repo. Do we need to apply the same fixes to the dev dep metapackages as to the templates?

STR:

1. Create a test project with a composer.json like:
   

   {
       "name": "xjm/test",
       "description": "Testing suggestion output for dependencies.",
       "type": "project",
       "license": "MIT",
       "authors": [
           {
               "name": "xjm",
               "email": "xjm@65776.no-reply.drupal.org"
           }
       ],
       "minimum-stability": "dev",
       "require": {
   	"local/core-dev": "10.0.x@dev"
       },
       "repositories": [
           {
               "type": "path",
               "url": "/Users/xjm/git/drupal/composer/Metapackage/DevDependencies"
           }
       ]
   }
   

2. Clone Drupal at the path specified in the composer.json, with the following hack to make it work:
   

   diff --git a/composer/Metapackage/CoreRecommended/composer.json b/composer/Metapackage/CoreRecommended/composer.json
   index 6da7fcbea8..8227608010 100644
   --- a/composer/Metapackage/CoreRecommended/composer.json
   +++ b/composer/Metapackage/CoreRecommended/composer.json
   @@ -1,5 +1,5 @@
    {
   -    "name": "drupal/core-recommended",
   +    "name": "local/core-recommended",
        "type": "metapackage",
        "description": "Core and its dependencies with known-compatible minor versions. Require this project INSTEAD OF drupal/core.",
        "license": "GPL-2.0-or-later",
   diff --git a/composer/Metapackage/DevDependencies/composer.json b/composer/Metapackage/DevDependencies/composer.json
   index e7c5b22011..891559dd40 100644
   --- a/composer/Metapackage/DevDependencies/composer.json
   +++ b/composer/Metapackage/DevDependencies/composer.json
   @@ -1,5 +1,5 @@
    {
   -    "name": "drupal/core-dev",
   +    "name": "local/core-dev",
        "type": "metapackage",
        "description": "require-dev dependencies from drupal/drupal; use in addition to drupal/core-recommended to run tests from drupal/core.",
        "license": "GPL-2.0-or-later",
   diff --git a/composer/Metapackage/PinnedDevDependencies/composer.json b/composer/Metapackage/PinnedDevDependencies/composer.json
   index 5deacd5c02..df91e937de 100644
   --- a/composer/Metapackage/PinnedDevDependencies/composer.json
   +++ b/composer/Metapackage/PinnedDevDependencies/composer.json
   @@ -1,5 +1,5 @@
    {
   -    "name": "drupal/core-dev-pinned",
   +    "name": "local/core-dev-pinned",
        "type": "metapackage",
        "description": "Pinned require-dev dependencies from drupal/drupal; use in addition to drupal/core-recommended to run tests from drupal/core.",
        "license": "GPL-2.0-or-later",
   
   

3. In the path repo, apply the patch from this issue:

   
   curl https://git.drupalcode.org/project/drupal/-/merge_requests/2479.diff | git apply --index -
   

4. In the test project, run composer install. Even with the patch applied, I still get the prompts:

   phpstan/extension-installer contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
   Do you trust "phpstan/extension-installer" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] y

   dealerdirect/phpcodesniffer-composer-installer contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
   Do you trust "dealerdirect/phpcodesniffer-composer-installer" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] 

Since this appears to also apply to phpstan as well as the dealerdirect thingamajig, this is maybe an out-of-scope issue that needs a followup.

I was unsuccessful in reproducing this locally for the templates, but going to go ahead and commit it based on the above feedback and see if it fixes packaging.

We can discuss the metapackages in a followup perhaps.

Hmmm except packaging still seems not fixed.

From @drumm, this was the output where packaging failed:

17:13:45  Installing dependencies from lock file (including require-dev)
17:13:45  Package operations: 59 installs, 0 updates, 0 removals
17:13:45    - Syncing drupal/coder (8.3.15) into cache
17:13:45      0 [>---------------------------]    0 [->--------------------------]
17:13:45    - Installing squizlabs/php_codesniffer (3.6.2): Extracting archive
17:13:46  
17:13:46  In PluginManager.php line 762:
17:13:46                                                                                 
17:13:46    dealerdirect/phpcodesniffer-composer-installer contains a Composer plugin w  
17:13:46    hich is blocked by your allow-plugins config. You may add it to the list if  
17:13:46     you consider it safe.                                                       
17:13:46    You can run "composer config --no-plugins allow-plugins.dealerdirect/phpcod  
17:13:46    esniffer-composer-installer [true|false]" to enable it (true) or disable it  
17:13:46     explicitly and suppress this exception (false)                              
17:13:46    See https://getcomposer.org/allow-plugins            

I spoke too soon. #22 was before the commit. It just took like 5 20 min to queue the packaging and CI jobs for the commit across the four branches. We'll know in an hour or so whether tests are passing and whether I can tag a silly release. :) Thanks everyone for your help here. 🤞

Looks like #3255749: Composer v2.2 prompts to authorize plugins was committed to 9.3.x. Does this need a 9.3.x backport?

Cherry-picked the 9.4.x commit to 9.3.x as well.