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