我正在为开发人员构建一个SDK，用于为电子商务平台构建模块，这些模块将为新启动使用我们的API。
显然这将是理想的使用作曲家，我现在正在做的。但是当我检查了大多数电子商务平台，或者至少是最流行的电子商务平台，他们没有使用composer。
所以我想知道什么是最好的方法来获得所有我当前的软件包需要的所有依赖，并将它们构建到一个独立的SDK。
这样我就可以有一个版本，将工作的作曲家和非作曲家的平台。
在设计模式方面是否有标准化的方法来做到这一点?我如何以有组织的方式布局所有依赖包?
因为这些电子商务平台不使用composer，这并不强制您将composer从等式中排除。你不能把你的包作为插件/模块/任何东西分发给那个特定的电子商务平台，但你仍然可以在生产中使用composer的自动加载器。
您可以准备在您的机器或构建服务器上部署的包，存档结果并分发存档。为了简单起见，我的示例将假设您将在本地机器上准备您的包:
创建临时工作目录:
$ mkdir -p ~/.tmp && cd ~/.tmp克隆你的包:
$ git clone <package><-
安装依赖一口> 1
$ cd ~/.tmp/<package> && composer.phar install --no-dev --optimize-autoloader或者如果您从自动工具中执行此操作:
$ cd ~/.tmp/<package> && composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader 删除
.git目录从
~/.tmp/<package>创建zip/tar归档文件分发存档
假设您的包已经是该电子商务平台的插件/模块，它可以像往常一样从zip/tar归档文件中安装。
1)关于--optimize-autoloader，请阅读Sven的回答，这解释了为什么在某些情况下不能帮助您的应用程序变得更快。
不要有依赖关系!
是的,认真。如果您要开发一个API客户端，使用Guzzle作为HTTP客户端，那么您必须做出选择:使用Guzzle版本3、4、5还是6?
Guzzle 3已停止维护并被遗弃。你不会想用它的
Guzzle 4也被认为是寿终正终的版本，因为版本5的发布速度非常快。没有人真正使用这个版本。
这归结为使用版本5或6。但是Guzzle在两个版本中使用相同的命名空间和可能相同的类名，但彼此不兼容。无论你选择哪个版本:你的客户会做出相反的选择——现在你有一个代码库，两个版本的Guzzle同时运行——这是行不通的。
如果您没有依赖项，但是在您自己的代码库中交付所有内容，那么您可以控制所有代码，并且减少了使用Composer作为轻松安装所有依赖项的工具的需要。您的包将包含所有内容，因此不太可能存在任何名称空间冲突。
你可以提供一个ZIP文件供下载。如果你额外提供一个composer.json，允许开发人员以这种方式包含你的包，每个人都会很高兴。
现在，在发现每个人都认为我建议不使用其他地方发明的东西是疯狂的之后，我挑战你再一次思考这种情况:你发现你必须生成的代码很可能包含在一个代码库中，而这个代码库不是由Composer管理的。也就是说，你根本不知道里面装的是什么软件。
这可能只是因为你在现有的代码库中有一个版本的Guzzle -无法检测到，因为没有composer.json。现在，您提供了自己的包和捆绑的Guzzle版本(不管它是如何出现的)。这可能会在某些时候因为冲突而导致整个软件崩溃，因为自动加载当然会在某些时候被合并，然后代码的某些部分会请求加载一些Guzzle类，这些类在两个不同版本的Guzzle中包含两次。
这是不可避免的。即使在能够使用Composer的幸运情况下，它也会发生冲突——软件不会崩溃，但整个包不会被安装。好处是:您会立即注意到这一点。
如果主要目标是交付一个任何人都可以在任何情况下使用的API客户端，而不使用依赖管理器:不要依赖!
或者，完全确定您知道哪个软件已经被使用，并创建一个在任何情况下都不会冲突的包。然而，这仍然是一个努力，因为可能还有其他插件也正在安装，其中可能包括冲突的软件。
我的中心观点是:如果你没有一个像Composer这样的依赖管理器来管理依赖关系，你最好不要在你自己的代码中有依赖关系，这样就可以非常容易地将你自己的代码包含在别人的代码库中。
上面的问题清楚地表明，在一般情况下，Composer不是一个选项。
现在隧道尽头有了一束光:当涉及到一般任务时，PHP-FIG已经开始标准化应该利用互操作性的接口。对于HTTP，标准是PSR-7。
你可以提供一个API SDK，它依赖(并带来)PSR-7接口，并要求SDK的用户提供一个实现该接口的HTTP客户端。
我看到这种方法的问题是，如果您尝试使用Guzzle，您仍然会遇到麻烦，例如出于同样的原因:现在唯一有效的选择是为SDK使用Guzzle 6 -如果Guzzle 5已经在其他地方使用了呢?冲突!好处是:如果您已经在使用Guzzle 5，可以通过使用任何其他支持PSR-7的HTTP客户端来避免使用Guzzle 6。