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

Question

我们正在开始一个新项目，我们正在使用Composer管理依赖项。我们可能会在Laravel 4之上构建我们的应用程序。但我们也将创建自己的库，我们将用于所有下一个项目，而不仅仅是这个。

所以，我们有这个可怕的疑问：使用作曲家开发图书馆的最佳方式是什么？

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

这看起来很可怕！

有更好的方法吗？

Answer 1

我认为有两种方法可以解决这个问题，我根据具体情况使用：

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

第三种方法是在应用程序的src /目录中开发代码，直到它大部分稳定，然后你可以将它作为新包提取出来并作为依赖项添加回来，然后再回到前两个我描述的方式，因为它将更加可行。

Answer 2

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

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

Answer 3

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

它应该只完成一项确切的任务。这可能是在一些提交之后完成的，所以最初创建库只需要一两个星期就可以获得稳定的第一个版本。此版本可以标记，然后在别处使用。

标记时，严格按照semantic versioning - 这样你就可以使用版本限制的库，如“~1.0”，意思是至少版本1.0，但是任何高达1.9999的内容都是可以接受的，只要它不是2.0（这意味着不兼容的变化）。

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

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

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

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