8

We're starting a new project, and we're managing dependencies with Composer. We'll probably build our app on top of Laravel 4. But we'll also create our own library, which we will use for all our next projects, not just this one.

So, we have this terrible doubt: what's the best way to develop a library using composer?

If we list that new library as a dependency, every time we modify it we will have to commit the change to the repository and then call composer update.

That seems terrible!

Is there a better way to do that?

4

3 回答 3

9

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

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

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

于 2013-11-04T13:13:06.243 回答
0

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

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

于 2013-11-04T12:44:43.910 回答
0

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

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

标记时，请严格遵循语义版本控制- 这样您就可以使用带有“~1.0”之类版本限制的库，这意味着至少是 1.0 版本，但只要不是 2.0（即将意味着不兼容的更改）。

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

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

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

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

于 2013-11-04T23:26:29.997 回答