0

大多数时候我都在开发 Joomla 扩展。经常发生需要重用帮助类、安装类等的情况。到目前为止，我只是复制粘贴的代码。我知道，我知道……但这始终是最快的解决方案，从长远来看，它是最慢的。我现在一直在思考如何在我的项目中管理依赖项管理。我已经测试了作曲家，我喜欢它，但它似乎不适合我。让我详细说明。假设我们有以下文件夹结构

projects
- library A
- library B
- project A
- project B
- project C

项目 A 和 B 都使用库 A 和 B，其中项目 C 仅使用库 A。如果我使用 composer，那么文件夹的结构将如下所示：

projects 
- library A
- library B
- project A
-- vendor
--- library A
--- library B
- project B
-- vendor
--- library A
--- library B
- project C
-- vendor
--- library A

我不知道——如果我使用不是我自己开发的第三方库，这可能会很好，但是如果我的硬盘上已经有库 A 和库 B 的代码——为什么我要复制*他们到供应商文件夹？不仅如此，每当我更新我的库时，我都需要在每个项目中进行 composer update 以获得最新的库版本。这对我来说似乎有点矛盾？

所以我想出的是->符号链接。我可以将符号链接放置到我的库 A 和 B，然后每当我进行更改时 -> 更改将自动应用于我的所有项目。

每当我压缩扩展时，我的 phing 脚本都会获取库并将它们包含在 zip 中。所以这似乎对我的开发工作流程有好处，但还有另一个问题。我的一些项目可以在 github 上找到，其他开发人员分叉它们，对它们做任何他们喜欢的事情等。现在我需要向他们解释，他们应该创建与我相同的目录结构，以便构建脚本能够运行。他们将下载项目 A，但他们必须去下载库 A 和 B。

这就是作曲家很棒的地方。但是如果我想轻松一点，我需要使用符号链接......你如何处理这种情况？您的工作流程是什么？您如何构建项目和库，以便不必到处复制代码，同时让其他开发人员在几秒钟内轻松上手？欢迎任何提示！

4

3 回答 3

0

如果您使用 Composer，并且开发“库 A”和“库 B” - 不要考虑可能使用它们的应用程序。当您更改这些库中的某些内容时，它必须自己运行。

当您开发“应用程序 A”时，不要考虑“此功能对应用程序 B 也有用”。想想“这个特性属于库 B”。把它放在那里，然后更新应用程序 A 以使用它。

您不需要同时更新应用程序 B，因为您发布了更新版本的库。

于 2013-10-31T13:51:42.233 回答
0

实际上，此请求存在一个未解决的问题https://github.com/composer/composer/issues/1299。不幸的是，过去几个月没有任何进展。

于 2014-05-04T18:31:38.843 回答
0

看到您已经对符号链接下定了决心，并假设所有这些项目都位于同一服务器上，我会提出以下建议；

共享的供应商目录

  • 供应商 A
    • 当前-> 0.3（符号链接到（所有）项目共享的“稳定”版本”）
    • 0.1
    • 0.2
    • 0.3
  • 供应商 B
    • 当前 -> 0.0.2
    • 0.0.1
    • 0.0.2
    • 0.0.3-β

因此，当您发布其中一个依赖项的新更新时，您可以通过切换项目版本来正确测试它们，如果您满意地将其应用于所有项目只是一个符号链接开关

项目 A 中的供应商目录

  • vendorA -> /shared/vendorA/current
  • vendorB -> /shared/vendorB/current

项目 B 中具有不同要求的供应商目录

  • 供应商A -> /shared/vendorA/0.1
  • vendorB -> /shared/vendorB/current

但是我真的很喜欢作曲家...

根据您是否还希望能够在 composer 中使用外部依赖项，您可能想朝这个方向尝试一些东西。

"autoload": { "psr-0": {"vendorA": "/shared/vendorA/current"} }
于 2013-10-31T09:28:58.037 回答