composer: How to treat allow-plugin's warnings as errors?

My composer.json:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://wpackagist.org",
            "only": [
                "wpackagist-plugin/*",
                "wpackagist-theme/*"
            ]
        }
    ],
    "require": {
        "php": "7.4.*",
        "ext-xml": "*",
        "ext-curl": "*",
        "ext-mysqli": "*",
        "ext-mbstring": "*",
        "johnpbloch/wordpress": "5.9.3",
        "wpackagist-theme/twentytwentytwo": "1.2"
    },
    "extra": {
        "wordpress-install-dir": "pub/wp",
        "installer-paths": {
            "pub/wp-content/mu-plugins/{$name}/": [],
            "pub/wp-content/plugins/{$name}/": [
                "type:wordpress-plugin"
            ],
            "pub/wp-content/themes/{$name}": [
                "type:wordpress-theme"
            ]
        }
    },
    "config": {
        "allow-plugins": {
            "johnpbloch/wordpress-core-installer": true
        }
    }
}

When I run this command:

composer install

I get the following output:

No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
Loading composer repositories with package information
Updating dependencies
Lock file operations: 8 installs, 0 updates, 0 removals
  - Locking composer/installers (v2.1.1)
  - Locking johnpbloch/wordpress (5.9.3)
  - Locking johnpbloch/wordpress-core (5.9.3)
  - Locking johnpbloch/wordpress-core-installer (2.0.0)
  - Locking wpackagist-theme/twentytwentytwo (1.2)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 8 installs, 0 updates, 0 removals
  - Installing johnpbloch/wordpress-core-installer (2.0.0): Extracting archive
  - Installing composer/installers (v2.1.1): Extracting archive
composer/installers contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe. See https://getcomposer.org/allow-plugins
You can run "composer config --no-plugins allow-plugins.composer/installers [true|false]" to enable it (true) or keep it disabled and suppress this warning (false)
  - Installing johnpbloch/wordpress-core (5.9.3): Extracting archive
  - Installing johnpbloch/wordpress (5.9.3): Extracting archive
  - Installing wpackagist-theme/twentytwentytwo (1.2): Extracting archive
Generating autoload files
1 package you are using is looking for funding.
Use the `composer fund` command to find out more!

And I expected this to happen:

returned code different from 0, because we don’t know allowed composer/installers or not

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 17 (11 by maintainers)

Commits related to this issue

Disallow plugins by throwing an exception if non-interactive to avoid half-broken runtime states (#10920) * Disallow plugins by throwing an exception if non-interactive to avoid half-broken runtime s... — committed to composer/composer by damz 2 years ago

Most upvoted comments

I think https://github.com/composer/composer/pull/10920 is a good solution as it fails hard when scripted/non interactive runs happen, thus avoiding any accidents when we cannot prompt the user.

Does that seem like a good outcome to everyone? I’ll aim to release this tomorrow morning (UTC)

Seldaek on Jul 4, 2022

We have received quite a number of support requests from our customers at Platform.sh because of this time-based backwards-compatibility break.

And yes, the key issue here is that composer install now just ignores plugins and still returns success. In many (possibly most) cases it just results into a completely broken application (because composer plugins are used to install modules in the right place for Drupal and Wordpress, etc.).

We were really scratching our heads too, some of our successful deployments started to act up strangely or were broken. Took us a bit to figure out that its due to missing allow-plugins config. We use a fixed composer version for all our deployment processes, and we didnt update the composer binary in that timeframe.

Im actually a bit in disbelief you guys added a time based bc break. I expect a versioned binary too keep its behaviour without external modification or updates. Yes i know now that there was a warning message, but many people apparently didnt notice too. At least an exception that would have stopped the deployments would have helped a lot.

marvinhinz on Jul 5, 2022

This is really necessary in order to catch issues early in CI, otherwise they just go unnoticed.

Furthermore, as we face similar problems with uncaught warnings in other commands (https://github.com/composer/composer/issues/10241), I’d really prefer to have a global --treat-warnings-as-errors flag, or else a way to catch all warnings with composer validate, so we don’t have to chase these problems down with an endless series of flags.

danepowell on Jul 1, 2022

Yeah I can see that there are cases where you may want to be alerted to this, but failing the process seems a bit extreme to me, and also it’d be really hard to implement cleanly I think. IMO this should anyway be caught at dev time when adding a dependency which is or requires a plugin.

Seldaek on Jul 1, 2022