Dependencies not mapped correctly

[tbmatuka]

My composer.json:

{
    "require": {
        "symfony/security-bundle": "^4.2"
    },
    "require-dev": {
        "symfony/security": "^4.2"
    }
}

Output of composer diagnose:

Checking composer.json: WARNING
No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.8.0
PHP version: 7.2.9
PHP binary path: /usr/bin/php

When I run this command with no other files or folders in the dir:

composer update --no-suggest

I get this output:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 16 installs, 0 updates, 0 removals
  - Installing symfony/contracts (v1.0.1): Loading from cache
  - Installing symfony/polyfill-ctype (v1.10.0): Loading from cache
  - Installing symfony/inflector (v4.2.0): Loading from cache
  - Installing symfony/property-access (v4.2.0): Loading from cache
  - Installing symfony/polyfill-mbstring (v1.10.0): Loading from cache
  - Installing symfony/http-foundation (v4.2.0): Loading from cache
  - Installing symfony/event-dispatcher (v4.2.0): Loading from cache
  - Installing psr/log (1.1.0): Loading from cache
  - Installing symfony/debug (v4.2.0): Loading from cache
  - Installing symfony/http-kernel (v4.2.0): Loading from cache
  - Installing symfony/security (v4.2.0): Loading from cache
  - Installing psr/container (1.0.0): Loading from cache
  - Installing symfony/dependency-injection (v4.2.0): Loading from cache
  - Installing symfony/filesystem (v4.2.0): Loading from cache
  - Installing symfony/config (v4.2.0): Loading from cache
  - Installing symfony/security-bundle (v4.2.0): Loading from cache
Writing lock file
Generating autoload files

And then when I run:

composer install --no-dev

I get this output:

Loading composer repositories with package information
Installing dependencies from lock file
Nothing to install or update
Generating autoload files

The problem is that the namespace "Symfony\Component\Security" is missing from autoload_psr4.php and autoload_static.php, even though the packages that syfmony/security replaces are dependencies of symfony/security-bundle. Nothing is installed in its place, and we have an unmet dependency.

I have this in a project where symfony/security isn't a dev dependency (I added it later to non-dev project dependencies to work around this issue), but adding it as a dev dependency here was the simplest way to test this.

Package symfony/security is the only dependency package that I have in my composer.lock that is a replacement for other packages and it's the only one with this issue, so I'm guessing that the issue is somewhere where that is resolved, but I'm not familiar enough with the composer codebase to pinpoint it.

[Seldaek]

If you rely on security classes in non-dev env, then why is it in require-dev? That will indeed mean the autoloader is not configured for it when you install with --no-dev.

[stof]

@Seldaek but symfony/security-bundle relies on these classes too. So it should not be considered as a dev-only requirement in the end.

[Seldaek]

Right, sorry I missed the fact that install --no-dev does not remove the package. Then I guess there's indeed a bug in the way the autoload dumper finds what is a dev and not a dev package.

Anyway, moving it to require for now would be a workaround I guess.

[naderman]

Just for the record, bug is in filterPackageMap in AutoloadGenerator which doesn't take provider/replacer names returned by package->getNames() into account but uses only package->getName()

[Great-Antique]

Another way to reproduce this issue:

composer require symfony/security-bundle:~4.1.0
composer require symfony/security-bundle:~4.2.0

First require installs symfony/security (because it's required by symfony/security-bundle:4.1.*) and writes it to composer.lock.
In symfony/security-bundle:4.2.* replace symfony/security with symfony/security-* packages that replaced by symfony/security which exists in composer.lock, so second require does not install symfony/security-*. The problem is that when you run composer dump-autoload --no-dev Composer checks root package requires and their requires (and so on) and dumps autoload for found packages, but symfony/security is not required now by any of root or required packages so it's not present in autoload. And symfony/security-* aren't present as well because there are not such packages because they are all replaced by symfony/security. As a result all classes from symfony/security-* are not autoloadable.

#7900 fixes this case