使用 Composer 开发库的最佳方法是什么？

Question

我们正在启动一个新项目，并且正在使用 Composer 管理依赖项。我们可能会在 Laravel 4 之上构建我们的应用程序。但我们还将创建自己的库，我们将在接下来的所有项目中使用它，而不仅仅是这个。

所以，我们有一个可怕的疑问：使用 composer 开发库的最佳方法是什么？

如果我们将该新库列为依赖项，则每次修改它时都必须将更改提交到存储库，然后调用composer update。

这看起来很糟糕！

有没有更好的方法来做到这一点？

Answer 1

我认为有两种方法可以处理，我根据情况使用：

• 该库是一个纯库，它是独立的，经过全面测试，并使用 TDD 进行开发，以确保一切正常。这样，我认为它可以与您描述的“提交、更新”周期一起使用。
• 您正在开发插件或必须集成到其他东西（应用程序/框架）中的东西，并且独立测试它更加困难，或者您正在与您的应用程序非常紧密地开发它。在这种情况下，需要库的 dev-master 版本，因此 Composer 使用 git clone 安装它（如果它已经作为标签安装，您将不得不 rm -rf vendor/your/library 强制重新安装而不是更新）。您还可以使用 --prefer-source 标志强制对标记的版本执行此操作。然后，一旦您在供应商目录中有一个克隆，您就可以非常轻松地直接在那里工作。如果您确实在团队中工作，但您仍然需要进行此提交，然后进行更新以确保其他人获得最新版本。

第三种选择是只在应用程序的 src/ 目录中开发代码，直到它基本稳定，然后您可以将其提取为新包并将其作为依赖项添加回来，然后回退到前两个我描述的方式，因为那样它会更加可行。

Answer 2

如果您将依赖项设置为存储库主分支而不是打包的分发文件，Composer 会将工作副本检出到供应商文件夹中。您可以在 vendor 文件夹中修改此工作副本，就像它是主项目的一部分一样，然后将其提交到自己的存储库中。不过，您确实必须确保在此之后 composer update 以使 composer.lock 文件与该库的开发保持同步。

它仍然是与依赖项一起开发项目的更方便的方法。

Answer 3

如果您的目标是开发一个真正出色的库，那么您应该尝试独立于您创建的任何其他软件来开发它。

它应该只完成一项确切的任务。这可能是在一些提交之后完成的，所以库的初始创建应该只需要一两个星期就可以达到稳定的第一个版本。并且这个版本可以被标记然后在其他地方使用。

标记时，请严格遵循semantic versioning - 这样您就可以使用具有“~1.0”之类版本限制的库，这意味着至少版本为 1.0，但最高 1.9999 的任何内容都是可以接受的，只要它是不是 2.0（这意味着不兼容的更改）。

当您发布新版本的库时，您真的不需要更新任何其他软件。如果您想包含已修复的错误，您只需要更新。如果没有错误修复，您可以更新，但不需要在库的新版本发布后立即这样做。

Composer 会处理您需要的所有依赖项。如果您启动一个新库，最重要的是从一开始就将composer.json 包含到存储库中。

如果您真的想在您编写的所有其他软件中始终包含最新版本的库怎么办？我不确定你是否意识到这有什么影响。这意味着您将其他软件严格绑定到最新的库版本。打破那个版本，或者引入一个讨厌的错误，你所有的软件都会崩溃。因此，是否能够更新实际上是一项功能。您会发现您可能使用的所有外部库都将遵循相同的发布机制：如果修复了重要错误或实现了合理数量的新功能，它们会标记新版本。他们不会等待您批准新版本 - 您必须通过明确更新到最新版本来批准您的软件中的新版本。这同样适用于内部库。

尽量避免摆弄这里提到的“dev-master”解决方案。它们可能有效，但 Composer 与标记版本一起使用时效果最佳。如果您的库有相当稳定的状态，请用“0.0.0”标记它，并在其他任何地方包含该版本，而不是“dev-master”。然后根据语义版本规则进行标记。