Mill项目中TestBaseModule模块依赖传递问题的技术解析

概述

在Mill构建工具的0.12.10版本中，开发者在使用TestBaseModule进行插件测试时遇到了一个关于依赖传递的典型问题。当两个ScalaModule之间存在moduleDeps关系时，ivyDeps无法正确地从依赖模块传递到测试模块，这给插件开发者的测试工作带来了困扰。

问题现象

具体表现为：假设我们有一个foo模块和一个bar模块，其中bar通过moduleDeps依赖于foo。foo模块中定义了ivyDeps依赖（如smithy4s-aws-kernel），但在bar模块中编译时却无法解析这些传递依赖，导致编译失败。

有趣的是，在Mill 0.13.0-M1版本中这个问题已经被修复，但0.12版本的用户仍然受此问题困扰。更奇怪的是，如果在测试代码中先打印transitiveIvyDeps，问题就会神奇地消失，这表明这是一个与依赖解析顺序相关的bug。

技术背景

TestBaseModule是Mill中专门用于测试的基础模块，按照设计原则，它应该是测试模块树的根节点，不应该有外部依赖。这种设计是为了保持测试环境的隔离性和可重复性。

在Mill 0.12.10中，TestBaseModule与其他模块的依赖关系处理存在缺陷，导致依赖无法正确传递。这主要是因为TestBaseModule的依赖解析机制与其他普通模块不同，没有正确处理跨模块的依赖传递。

解决方案

根据Mill核心开发者的建议，正确的做法是将所有测试模块组织在一个TestBaseModule内部，而不是让多个TestBaseModule相互依赖。这样可以确保依赖关系的正确传递和解析。

例如：

object base extends TestBaseModule {
  object foo extends ScalaModule {
    // 配置...
  }

  object bar extends ScalaModule {
    override def moduleDeps = Seq(foo)
    // 配置...
  }
  
  lazy val millDiscover = Discover[this.type]
}

这种组织方式确保了所有测试模块都在同一个TestBaseModule上下文中，依赖关系能够正确传递。

版本差异分析

在Mill 0.13.0-M1中，这个问题被修复了，使得TestBaseModule之间的依赖传递能够正常工作。但考虑到向后兼容性和设计初衷，即使在0.13版本中，也不推荐让TestBaseModule相互依赖。

最佳实践建议

1. 单一TestBaseModule原则：所有测试模块应该组织在一个TestBaseModule内部
2. 模块化设计：在TestBaseModule内部可以自由定义多个子模块和它们之间的依赖关系
3. 避免跨TestBaseModule依赖：即使在高版本中能够工作，也不推荐这种做法
4. 明确依赖边界：测试模块的依赖应该自包含，减少对外部环境的依赖

总结

这个问题揭示了测试模块设计中的一个重要原则：测试环境应该尽可能独立和自包含。通过将相关测试模块组织在同一个TestBaseModule下，不仅可以避免依赖传递问题，还能提高测试的可维护性和可靠性。对于Mill插件开发者来说，理解这一设计理念比单纯依赖特定版本的修复更为重要。