我想你在这里有几个选择:
如 @Loek指出 ,你可以用一个 的 路径 强> 库。这是为了解决通常不属于VCS(版本控制系统,如Git)或文件工件的场景。根据文档,您可以像这样使用它:
{ "repositories": [ { "type": "path", "url": "../../packages/my-package", "options": { "symlink": true } } ], "require": { "my/package": "*" } }
要注意的最重要的部分是:
的 如果可能,本地包将被符号链接 强> ,在这种情况下 控制台中的输出将读取Symlinking ../../packages/my-package。如果包不可能进行符号链接 将被复制。在这种情况下,控制台将输出Mirrored ../../packages/my-package。 而不是默认的后备策略 的 你可以强制使用符号链接 “symlink”:true或使用“symlink”镜像:false选项 强> 。强制 从a部署或生成包时,镜像可能很有用 单片存储库。
的 如果可能,本地包将被符号链接 强> ,在这种情况下 控制台中的输出将读取Symlinking ../../packages/my-package。如果包不可能进行符号链接 将被复制。在这种情况下,控制台将输出Mirrored ../../packages/my-package。
而不是默认的后备策略 的 你可以强制使用符号链接 “symlink”:true或使用“symlink”镜像:false选项 强> 。强制 从a部署或生成包时,镜像可能很有用 单片存储库。
这个选项对我来说最有意义,也是我个人喜欢的。
另一种选择是使用 COMPOSER 环境变量 如此处所述 。这将允许您加载不同的 composer.json 文件比默认命名的文件。所以你可能有两个文件,根据你设置环境变量的内容,它会加载适当的文件并创建一个匹配的锁文件:
COMPOSER
composer.json
好的,那你为什么要这样做呢?好吧,由于您尝试在本地处理程序包(使用活动符号链接)的方式,但不希望在生产中发生这种情况,如果第一个选项没有,这可能会有效。
我应该注意到,您的目标始终应该是在环境中(即本地,登台,生产)使用一个相同的配置。我知道您希望在应用程序中立即看到对存储库的本地更改,并且对每个更改进行提交/推送/拉取过程非常荒谬。
https://github.com/composer/composer/issues/601
https://github.com/composer/composer/issues/4011
https://github.com/franzliedke/studio