我正在为开发人员构建一个 SDK，用于为电子商务平台构建模块，这些平台将使用我们的 API 来创建新的初创公司。
显然，使用我现在正在做的作曲家是理想的选择。但当我检查目前大多数电子商务平台，或者至少是最受欢迎的平台时，他们不使用 Composer。
所以我想知道获取我当前所有包所需的所有依赖项并将它们构建到独立 SDK 中的最佳方法是什么。
这样我就可以获得一个既适用于 Composer 又适用于非 Composer 的平台的版本。
在设计模式方面是否有标准化的方法来做到这一点？我将如何以任何有组织的方式布置所有依赖包？
Don't have dependencies!
Yes, seriously. If you'd develop an API client that would use Guzzle as the HTTP client, you'd have to make a choice: Use Guzzle version 3, 4, 5 or 6?
Guzzle 3 is out of maintenance and abandoned. You wouldn't want to use it.
Guzzle 4 is also considered end-of-life, because version 5 came very fast. Nobody really use this version.
This boils down to using either version 5 or 6. But Guzzle is using the same namespace and likely the same class names in both versions, but is incompatible to each other. No matter which version you choose: Your customer will have made the opposite choice - and now you have a codebase where two versions of Guzzle are running at the same time - this will not work.
If you don't have dependencies, but deliver everything within your own codebase, you have all of your code under your control, and are reducing the need to use Composer as a tool to easily install all your dependencies. Your package will have everything already included, it's unlikely that there will be any namespace conflicts.
You'd be able to offer a ZIP file for download. And if you additionally offer a composer.json to allow developers to include your package that way, everyone will be happy.
Update
Now after finding out that everyone thinks I am crazy proposing not to use stuff invented elsewhere, I challenge you to think about the situation once again: You find that you have to produce code that will likely be included in a codebase that is NOT managed with Composer. That means you have no idea what kind of software is put together there.
可能只是因为您在现有代码库中有一个 Guzzle 版本 - 无法检测到，因为没有composer.json. 现在，您可以提供自己的软件包以及捆绑的 Guzzle 版本（无论以何种方式使其出现在那里）。这可能会在某个时候因为冲突而导致整个软件崩溃，因为自动加载当然会在某个时候被合并，然后代码的某些部分将请求加载一些 Guzzle 类，该类在两个不同版本中包含两次咕咕的。
在这种情况下应该发生什么？事情会崩溃！
而这种情况的发生是不可避免的。即使幸运的是能够使用Composer，它也会发生冲突——软件不会崩溃，但整个包不会被安装。好处是：您会立即注意到这一点。
如果主要目标是提供一个任何人都可以在任何情况下使用的 API 客户端，而无需使用依赖项管理器：不要有依赖项！
或者，完全确定您知道哪个软件已经在使用，并创建一个在任何情况下都不会发生冲突的包。然而，这仍然是一项工作，因为可能还安装了其他插件，其中可能包括冲突的软件。
我的中心点是：如果您没有像 Composer 这样能够管理依赖项的依赖项管理器，那么您最好不要在自己的代码中包含依赖项，这样可以非常轻松地将自己的代码包含在其他人的代码库中。
上面的问题清楚地表明，在一般情况下，Composer 不是一个选择。
现在隧道尽头出现了一盏灯：当涉及到一般任务时，PHP-FIG 已经开始标准化应该利用互操作性的接口。对于 HTTP，标准是 PSR-7。
您可以提供一个依赖于（并附带）PSR-7 接口的 API SDK，并要求 SDK 的用户提供一个实现此接口的 HTTP 客户端。
我发现这种方法的问题是，如果您出于同样的原因尝试使用 Guzzle，您仍然会遇到麻烦：现在唯一有效的选择是使用 Guzzle 6 作为 SDK - 如果 Guzzle 5 已在其他地方使用怎么办？冲突！好处是：如果您已经在使用 Guzzle 5，则可以通过使用任何其他支持 PSR-7 的 HTTP 客户端来避免使用 Guzzle 6。