我们正在开始一个新项目，我们正在使用Composer管理依赖项。我们可能会在Laravel 4之上构建我们的应用程序。但我们也将创建自己的库，我们将用于所有下一个项目，而不仅仅是这个。
所以，我们有这个可怕的疑问：使用作曲家开发图书馆的最佳方式是什么？
如果我们将新库列为依赖项，那么每次修改它时，我们都必须将更改提交到存储库，然后调用composer update。
这看起来很可怕！
有更好的方法吗？
答案 0 :(得分：7)
我认为有两种方法可以解决这个问题，我根据具体情况使用：
rm -rf vendor/your/library强制重新安装而不是更新）。您还可以使用--prefer-source标志为标记版本强制执行此操作。然后，一旦你在供应商目录中有一个克隆，你就可以很容易地直接在那里工作。如果您在团队中工作，但仍需要执行此提交，然后进行更新以确保其他人获得最新版本。第三种方法是在应用程序的src /目录中开发代码，直到它大部分稳定，然后你可以将它作为新包提取出来并作为依赖项添加回来，然后再回到前两个我描述的方式，因为它将更加可行。
答案 1 :(得分：0)
如果将依赖项设置为存储库主分支而不是打包的分发文件，则Composer会将工作副本签出到vendors文件夹中。您可以在vendors文件夹中修改此工作副本，就好像它是主项目的一部分，但随后将其提交到自己的存储库中。在确保composer update之后，您确实必须确保composer.lock文件与该库的开发保持同步。
与依赖项一起开发项目仍然是更方便的方法。
答案 2 :(得分：0)
如果您的目标是开发一个真正令人敬畏的库，那么您应该尝试独立于您创建的任何其他软件开发它。
它应该只完成一项确切的任务。这可能是在一些提交之后完成的，所以最初创建库只需要一两个星期就可以获得稳定的第一个版本。此版本可以标记，然后在别处使用。
标记时，严格按照semantic versioning - 这样你就可以使用版本限制的库，如“~1.0”，意思是至少版本1.0，但是任何高达1.9999的内容都是可以接受的，只要它不是2.0（这意味着不兼容的变化）。
然后，当您发布新版本的库时，您真的不需要更新任何其他软件。如果要包含修复的错误，则只需要更新。如果没有错误修正，可以更新，但在库的新版本发布后不需要立即更新。
Composer将负责您需要的所有依赖项。如果您启动新库，最重要的是从一开始就将composer.json包含在存储库中。
如果您真的想在您编写的其他软件中始终包含最新版本的库，该怎么办？我不确定你是否意识到这有什么影响。这意味着您将其他软件严格绑定到最新的库版本。打破那个版本，或引入一个令人讨厌的bug，以及所有软件中断。因此能够更新或不实际是一个功能。您会发现您可能使用的所有外部库都将遵循相同的发布机制：如果修复了重要错误，或者实现了合理数量的新功能，它们会标记新版本。他们不等您批准新版本 - 您必须通过明确更新到最新版本来批准软件中的新版本。同样适用于内部库。
尽量避免摆弄这里提到的“dev-master”解决方案。它们可能有效，但如果与标记版本一起使用，Composer的效果最佳。如果您的库状态相当稳定，请将其标记为“0.0.0”，并将该版本包含在其他地方，而不是“dev-master”。然后根据语义版本规则进行标记。