在作曲家依赖项中使用包分叉

Question

我正在开发一个laravel包（我们称之为包a），它需要另一个包（包B）https://github.com/dropbox/dropbox-sdk-php).

我做了一个B包的叉子(https://github.com/EmilioBravo/dropbox-sdk-php)，在新的分支“fix64”中进行了一些更改，并在composer中添加my GitHub repo作为存储库。composer文档中指出的包A的json：

"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/EmilioBravo/dropbox-sdk-php"
    }
],
"require": {
    "php": ">=5.4.0",
    "illuminate/support": "4.2.*",
    "dropbox/dropbox-sdk": "dev-fix64"
},

如果我从包A中调用composer update，它会正确下载我的fork，但是，如果我在另一个项目（项目C）中使用包A作为依赖项并从中调用composer update，composer说它找不到dev-fix64。

问题1

- emilio-bravo/platform dev-dropboxfix requires dropbox/dropbox-sdk dev-fix64 -> no matching package found.

>

emilio-bravo/平台dev-dropboxfix的安装请求-

只有当我在项目C中添加我的回购作为存储库composer.json它才能找到我的分叉分支。

我发现的另一种解决方法是将我的fork克隆到satis存储库中。

但这感觉不对。如何让composer从GitHub找到我的叉子？

Answer 1

将自定义存储库添加到主项目是使Composer了解新源的唯一方法。

它是故意这样做的，因为否则回购可能会增加回购可能会增加回购...没有保证有一个有限的回购清单。

此外，添加一个回购不会对在那里找到哪个软件做出任何声明，作曲家将扫描每个标签和分支。理论上，存储库可以为一个完全不同的、众所周知的包拥有另一个分支，提供它的新版本，并添加一些恶意行为。

一般来说，对于防止远程代码执行，Composer似乎非常适合，除了不知情的人做出错误的决策。

因此，如果您在PackageGist上发布的包中发现错误。对于每个人来说，最好的方法就是提出一个请求。第二个最好的方法是用新名称将项目分叉，并将其发布在PackageGist上。组织也是如此。使用具有相同项目名称的分叉回购协议并将Composer指向它来修补问题是最糟糕的解决方案，通常仅适用于您自己项目的依赖项。