Composer本地包依赖配置：@dev与dev-main该选哪一个？

你当前遇到的问题是：用path类型仓库管理同Git仓内的本地Composer包时，用@dev引入依赖会让composer.lock记录当前分支名，特性分支合并删除后，lock里的分支引用就失效了——这种场景虽然不会彻底导致安装失败（因为path仓库会优先读取本地文件），但lock文件状态会不一致，容易给团队协作添乱。下面是几个可行的选型方案：

方案1：用固定版本号替代@dev #

• 给每个本地包的composer.json设置明确版本，比如开发阶段用"version": "1.0.x-dev"，稳定版本用语义化号如"version": "1.0.0"。
• 根目录composer.json直接指定这个版本：

  {
    "require": {
        "app/local": "1.0.x-dev"
    }
  }
  

• 优势：lock文件会记录版本约束而非临时分支名，分支删除后不会出现无效引用；版本规则清晰，团队能统一依赖状态。
• 注意：如果本地包频繁迭代，需要定期在根目录跑composer update app/local更新lock里的本地文件哈希（path仓库会记录这个哈希来保证一致性）。

方案2：@dev配合分支别名使用 #

• 在本地包的composer.json里给分支设置别名，比如：

  {
    "extra": {
        "branch-alias": {
            "dev-main": "1.0.x-dev",
            "dev-feature/xxx": "1.0.x-dev"
        }
    }
  }
  

• 根目录composer.json引用别名对应的版本：

  {
    "require": {
        "app/local": "1.0.x-dev"
    }
  }
  

• 优势：lock文件会记录别名对应的版本号，而非临时分支名；就算特性分支被删，别名依然有效，从根源避免无效引用问题。
• 注意：得提前约定好分支别名规则，确保所有开发分支都能对应到合适的别名版本。

方案3：禁用lock文件对path包的分支记录（仅临时/单人场景） #

• 在根composer.json里配置让Composer不把path包的分支信息写入lock：

  {
    "config": {
        "lock": false
    }
  }
  

• 或者用Composer 2.2+的特性单独排除特定包：

  {
    "config": {
        "lock": {
            "exclude": ["app/local"]
        }
    }
  }
  

• 优势：彻底避免lock文件出现无效分支引用；
• 劣势：失去了lock文件统一依赖版本的核心作用，团队成员的依赖状态可能不一致，只适合单人开发或临时测试场景。

额外协作规范建议 #

• 要求团队成员在合并特性分支后，必须执行composer update app/local更新根目录的lock文件并提交，保证lock始终引用有效状态。
• 可以在CI/CD流程里加检查：如果lock文件里存在已删除的分支引用，触发提醒或自动更新。

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