我正在编写一个其他包裹B所需的包裹A,我现在暂不发布。在某些时候,A将被改变为使用它自己B.可能它们应该在同一个包装中,但是我更喜欢将这两个东西分开,只是为了清洁'更重要的是,因为B只是对A的开发依赖。
package A requires-dev B
package B requires A
我很好奇这是否可能。我也很好奇,如果它是相同的:
package A requires B
package B requires A
...和...
package A requires B
package B requires C
package C requires A
......或更复杂的案例。我会遇到什么问题?
谢谢。
答案 0 :(得分:1)
这里有一个更宽泛的,而不是特定于PHP的答案:循环依赖从不是一个好主意。
你看,你"分开"将东西分成不同的包/模块/你的名字 - 以便为它们提供有用的结构。创建"模型"这有助于您处理代码的复杂性。
换句话说:您想要定义architecture。循环依赖通常被视为"难闻的气味"在设计中。
因此,您不应该问它是否有效?",但是"是否有更好的方法来解决这个问题?"
答案 1 :(得分:1)
正如Ghost所说,循环依赖会产生比他们要解决的问题更多的问题。如何解决或消除循环依赖关系完全取决于用例,但无论如何我都想提供一个示例。
我有两个包裹:
翻译工具(B)需要文件系统实用程序(A)来创建和保存文件。但是,文件系统实用程序(B)也使用了翻译工具(A),因为它定义了需要翻译的文本。
仅就原理而言,这似乎没有什么不对。但是,这引起了很多问题,尤其是当我开始添加持续集成时:由于周期性的依赖,composer无法解析可安装的程序包,因此测试无法运行。
就我而言,解决方案是使翻译工具依赖项在文件系统实用程序中为可选,因为这对于使用该包并不重要。我将翻译工具移至suggest
的{{1}}部分:
composer.json
当然不可能总是使其中一个软件包成为可选软件包。