Composer私有包循环依赖问题求解：proposal与supplier互相依赖

当两个私有包proposal和supplier出现双向循环依赖时，可以通过以下几种方式解决：

• 提取公共代码到独立共享包
  把两个包中互相依赖的功能模块抽离出来，新建一个独立的私有包（比如atrialab/common），将公共逻辑迁移到这个新包中。随后更新proposal和supplier的composer.json，移除对彼此的依赖，改为依赖这个新的共享包。这种方式从根源上打破循环，是最规范的长期解决方案。

• 将非强制依赖改为软依赖
  如果supplier对proposal的依赖仅为可选功能，而非核心必需，可以把依赖从require移到suggest字段，同时在代码中做条件判断：

  1. 在supplier的composer.json中修改：

     "suggest": {
       "atrialab/proposal": "用于支持XX功能"
     }
     

  2. 在supplier的代码中，通过class_exists()或interface_exists()判断proposal的类是否存在，仅在存在时调用相关功能，避免强制依赖。

• 重构代码消除双向依赖
  梳理两个包的调用逻辑，调整依赖方向：

  • 让supplier不直接依赖proposal的具体类，而是定义通用接口，由proposal实现该接口。
  • 在supplier的方法中接收接口实例，由上层项目（或proposal自身）注入实现类，这样supplier的composer.json无需声明对proposal的依赖，从而消除循环。

• 临时方案：分支别名或版本指定（不推荐长期使用）
  若仅为开发阶段临时绕过，可以给其中一个包设置分支别名，在另一个包中依赖该别名版本：
  比如在proposal的composer.json中添加：

  "extra": {
    "branch-alias": {
      "dev-main": "1.1.x-dev"
    }
  }
  

  然后在supplier的composer.json中依赖"atrialab/proposal": "dev-main"。但这种方法只是临时 workaround，无法解决本质问题，不建议用于生产环境。

内容的提问来源于stack exchange，提问作者sajadsholi