prevent duplicate vendor

[rino1]

I created two packages.
Here are the related composer.json files

{
    "name": "my/sub1",
    "version": "1",
    "require": {
       "my/sub2": "^1.0"
    }
}

{
    "name": "my/sub2",
    "version": "1"
}

Note that the my/sub1 package requires the my/sub2 package.

We download

$ composer require my/sub1
[CUT]

Let's see what happened

$ find
[ONLY SUMMARY]
./vendor/my/sub1
./vendor/my/sub1/vendor/my/sub2
./vendor/my/sub2

But I would have liked to be downloaded only the ./vendor/my/sub1 and ./vendor/my/sub1/vendor/my/sub2 directory, and not also ./vendor/my/sub2
It's possible?

[stof]

/vendor/my/sub1/vendor/my/sub2 should not exist, unless you committed your vendor folder inside the my/sub1 package (which should not be done).

Composer will never create a vendor folder nested inside an installed vendor package.

[stof]

with those anonymised packages with no idea where they come from, there is nothing I can do to help you understand why this /vendor/my/sub1/vendor folder exists

[rino1]

+ rm -rf one/composer.lock one/vendor root/composer.json root/composer.lock root/vendor
+ tree -a
.
├── .config -> ../.config/
├── one
│   ├── composer.json
│   └── script
├── response
├── root
└── two
    ├── composer.json
    └── script

4 directories, 5 files
+ cat .config/composer/config.json
{
    "repositories": {
        "one": {
            "type": "path",
            "url": "$PWD/one"
        },
        "two": {
            "type": "path",
            "url": "$PWD/two"
        }
    }
}
+ cat one/composer.json
{
    "name": "package/one",
    "version": "1",
    "require": {
       "package/two": "^1.0"
    }
}
+ cat two/composer.json
{
    "name": "package/two",
    "version": 1
}
+ cat one/script
#!/bin/bash -eu
echo $0: Hello world!
# do something...
sub_script=$(/usr/bin/dirname "$0")/vendor/package/two/script
$sub_script && echo OK: $sub_script called
# do something...
+ cat two/script
#!/bin/bash -eu
echo $0: Hello world!
# do something...
+ one/script
one/script: Hello world!
one/script: line 5: one/vendor/package/two/script: No such file or directory
+ composer update -d one
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking package/two (1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing package/two (1): Symlinking from /var/tmp/duplicate-vendor/public/two
Generating autoload files
+ one/script
one/script: Hello world!
one/vendor/package/two/script: Hello world!
OK: one/vendor/package/two/script called
+ composer require -d root package/one
Using version ^1.0 for package/one
./composer.json has been created
Running composer update package/one
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
  - Locking package/one (1)
  - Locking package/two (1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Installing package/two (1): Symlinking from /var/tmp/duplicate-vendor/public/two
  - Installing package/one (1): Symlinking from /var/tmp/duplicate-vendor/public/one
Generating autoload files

Now let's pay close attention

+ cat response
#!/bin/bash -u
rootVendorDir=root/$1
oneVendorDir=one/$1
if diff -rq $rootVendorDir $oneVendorDir; then
    echo $rootVendorDir it a duplicate of $oneVendorDir
    if ! grep -r $1 root && grep -r $1 one; then
        echo "Only 'one' package use $oneVendorDir. Therefore downloading of $rootVendorDir should be avoided."
    fi
fi

Final verdict

+ ./response vendor/package/two
root/vendor/package/two it a duplicate of one/vendor/package/two
one/script:sub_script=$(/usr/bin/dirname "$0")/vendor/package/two/script
Only 'one' package use one/vendor/package/two. Therefore downloading of root/vendor/package/two should be avoided.

[stof]

OK, this is because you use a path repository, which creates a symlink, while you also installed dependencies inside that path by using it as a root package. That's one one/vendor/package/two exists.
But it your main project, this one/vendor/package/two won't be used as composer won't be aware about it and won't register any autoloading for it.

[rino1]

FALSE!!!

I had forgotten...

+ cd root

I created the file my-script

+ cat my-script
#!/bin/bash
$(/usr/bin/dirname "$0")/vendor/package/one/script

+ ./my-script
./vendor/package/one/script: Hello world!
./vendor/package/one/vendor/package/two/script: Hello world!
OK: ./vendor/package/one/vendor/package/two/script called

+ !! | grep one/vendor/package/two && echo one/vendor/package/two FOUND
./vendor/package/one/vendor/package/two/script: Hello world!
OK: ./vendor/package/one/vendor/package/two/script called
one/vendor/package/two FOUND

[rino1]

After this umpteenth clarification, however, I expected a courtesy response (at least one opinion) on the final verdict: #11403 (reply in thread) (last part)

[rino1]

I resume the discussion for some clarification

/vendor/my/sub1/vendor/my/sub2 should not exist, unless you committed your vendor folder inside the my/sub1 package (which should not be done).

But if I have unit tests to be performed, I have to give the command

composer require --dev phpunit/phpunit && vendor/bin/phpunit

which will inevitably be to create the vendor directory.

So what do you do?

[rino1]

Nothing?

[mbabker]

This is just how Composer works, I suggest taking a read over https://getcomposer.org/doc/05-repositories.md#path for more information.

When Composer installs a package from a path repository and it makes a symlink, then whatever you've got loaded in that symlinked path is going to be present in the parent project. The presence of a vendor folder in one of those symlinked projects shouldn't be an issue unless something is loading the autoloader from that nested vendor (so the main application ends up loading vendor/autoload.php and vendor/anon/package1/vendor/autoload.php as an example), it'll be annoying in an IDE if it shows multiple class declarations but that's really the extent of the damage that should be able to do.

[rino1]

So the ideal would be to avoid having the vendor/anon/package1/vendor directory, avoiding to run

composer require -d vendor/anon/package1 --dev phpunit/phpunit

But if I have unit tests into anon/package1 to be run, I have to give the command

vendor/anon/package1/vendor/bin/phpunit

This forces me to download the phpunit/phpunit composer package, otherwise would answer me

vendor/anon/package1/vendor/bin/phpunit: not found

That's what I had already said here #11403 (comment)

So what do you do?

Unfortunately @stof no longer gave any answer