Vendor Expose fails when referencing repositories of type path

[NightJar]

vendor-plugin/src/Library.php

Lines 47 to 52 in 87769ad

	public function __construct($basePath, $libraryPath, $name = null)
	{
	$this->basePath = realpath($basePath);
	$this->path = realpath($libraryPath);
	$this->name = $name;
	}

On a unix-like system symlinks are used by default.

https://getcomposer.org/doc/05-repositories.md#path

The local package will be symlinked if possible, in which case the output in the console will read Symlinking from ../../packages/my-package.

This leads realpath to be not what is expected (the module's name attribute), but instead the name of the linked local (e.g. development) repository. Vendor expose then creates a dud path where files exposed are then not found because of 404s.

e.g. an exposure of public/_resources/-dir/client/dist for someone/module, which may be actively being worked on and defined as below to avoid continual necessitation of commits and pushes:

"someone/module": {
    "type": "path",
    "url": "../working-dir"
}

[NightJar]

https://stackoverflow.com/questions/62793104/composer-vendor-expose-copy-not-picking-up-the-correct-name-for-my-silverstrip-m

[robbieaverill]

Have you tried using the "copy" strategy rather than symlink for the vendor-expose command? I'm not sure it would make a difference, but worth checking. Also another thing to check is whether silverstripe/silverstripe-framework#9569 might fix this.

[NightJar]

Yeah, copy was tried also. Didn't seem to affect the results.
In the end though @andrewandante couldn't replicate the issue, so it was very weird. Perhaps it's composer and or php version dependent.

I don't think this composer plugin relies on Silverstripe core concepts such as module manifest, but I could be mistaken.

[andrewandante]

Yeah, copy was tried also. Didn't seem to affect the results.
In the end though @andrewandante couldn't replicate the issue, so it was very weird. Perhaps it's composer and or php version dependent.

I don't think this composer plugin relies on Silverstripe core concepts such as module manifest, but I could be mistaken.

I tried with a really simple version of this:

• clone recipe-cms
• clone the silverstripe-module template at the same level
• rename the module to andante/silverstripe
• add andante/silverstripe to the composer.json of recipe-cms and the following:

    "repositories": [
        {
            "type": "path",
            "url": "../silverstripe-module"
        }
    ],

• composer update
• composer vendor-expose

and everything looked right. I'm running WSL (debian) and OP was running Laravel Homestead through Vagrant, so it's possible there was a weird file sync or mount issue or something, because they were able to fix it with a clean install.

[Zauberfisch]

bug definitely still present, just ran into this issue on linux

[Zauberfisch]

ok, I think I've identified the problem:

it happens when a module is developed outside of the project and synced into the project using symlinks (which is afaik the recommended way to develop modules). So:

    "repositories": {
        "silverstripe-foo-module": {
            "type": "path",
            "url": "../srv/some-long-path/silverstripe-foo-module",
            "options": {
                "symlink": true
            }
        }
    }

What I happens is:

• composer symlinks the module from /srv/some-long-path/silverstripe-foo-module to /srv/http/my-project/vendor/zauberfisch/silverstripe-foo-module
• the silverstripe vendor plugin will find the module, and it will make it relative by doing substr($this->path, strlen($this->basePath) in Library.php#L137 (Which usually is substr('/srv/http/vendor/silverstripe/asset-admin', strlen('/srv/http'))
• but, in this case realpath for /srv/http/my-project/vendor/zauberfisch/silverstripe-foo-module returns /srv/some-long-path/silverstripe-foo-module
• so what happens is substr('/srv/some-long-path/silverstripe-foo-module', strlen('/srv/http')) which then returns some cut-off string. in this case
• now the files are in /srv/http/public/_resources/-long-path/silverstripe-foo-module

---

Work around: don't use symlink for adding the module to your project.
But this of course has the downside that you'll have to run composer every single time you change anything in the module (so a pretty bad workaround)

    "repositories": {
        "silverstripe-foo-module": {
            "type": "path",
            "url": "../srv/some-long-path/silverstripe-foo-module",
            "options": {
                "symlink": false
            }
        }
    }

[NightJar]

As a weird side note I've used type: "url" with what should have been path in the past with 100% success (where url: "../path" or maybe absolute, I can't recall).
So that might also be an option to sidestep this issue.

This worked as I tend not to update (composer update) during module development, as focus is on the module rather than the system. Updating the system would reset any unsaved work - although composer should (one would hope) give a warning about this as it does with other files.

It also depends on composer knowing it's a dev level requirement though, as opposed to a release artifact unpacked. So one would also have to ensure that fact e.g. require "vendor/module": "dev-branchname" and presumably have minimum-stability: "dev" set.

[Zauberfisch]

still an issue with silverstripe/framework 5.2.22 / silverstripe/vendor-plugin 2.0.3