ScalaJS模块拆分功能在v1.19.0版本中的回归问题分析

在ScalaJS 1.19.0版本中，当开发者同时启用模块拆分功能并禁用优化器时，会出现一个严重的运行时断言错误。这个问题主要影响使用ModuleSplitStyle.SmallModulesFor或ModuleSplitStyle.SmallestModules配置的项目，而使用ModuleSplitStyle.FewestModules的项目则不受影响。

问题现象

当开发者在项目中配置了细粒度模块拆分策略并执行fastLinkJS任务时，会抛出以下关键错误信息：

java.lang.AssertionError: assertion failed: java.util.function.Supplier.$$Lambda$... was not put in a module but has definitions

这个错误表明系统在模块拆分过程中发现了一个未被正确分配到任何模块的Lambda类定义。值得注意的是，该问题仅在禁用优化器（withOptimizer(false)）的情况下出现，执行fullLinkJS时不会触发此错误。

技术背景

ScalaJS的模块拆分功能允许将代码分割成多个输出文件，这在现代Web开发中对于实现按需加载非常重要。系统提供了三种主要的拆分策略：

1. FewestModules：生成尽可能少的模块文件
2. SmallModulesFor：为指定包生成独立模块
3. SmallestModules：为每个类生成独立模块

在底层实现中，模块拆分器需要正确处理所有类定义及其依赖关系，包括由Java函数式接口生成的Lambda类。

问题根源

经过分析，这个问题源于分析器(Analyzer)在处理Java函数式接口的Lambda实例化时，没有正确添加实例依赖关系。具体来说：

1. 对于普通类实例化，分析器会调用addInstanceDependency来建立依赖关系
2. 但对于Lambda实例化，虽然会创建对应的Lambda类信息，却遗漏了这个关键调用

这种不一致导致在模块拆分阶段，某些Lambda类无法被正确追踪和分配到适当的模块中。

解决方案与修复

项目维护团队已经提交修复，确保Lambda实例化也会正确添加实例依赖关系。修复的核心是修改分析器逻辑，使其在处理Lambda表达式时与处理普通类实例化保持一致的依赖追踪行为。

对于受影响的用户，可以采取以下临时解决方案：

1. 在等待新版本发布期间，可以重新启用优化器（这是推荐做法）
2. 或者改用FewestModules拆分策略

最佳实践建议

1. 优化器使用：在开发环境中保持优化器启用通常能带来更好的性能，因为：

   • ScalaJS优化器是增量式的，开发模式下运行效率很高
   • 生成的代码更精简，能减少浏览器需要加载的代码量
   • 与Vite等工具的minifier功能互补而非冲突

2. 调试技巧：当遇到源码映射(source map)问题时：

   • 首先确认withSourceMap(true)已设置（默认已启用）
   • 仅在必要时临时禁用优化器进行调试
   • 注意后续工具链可能对源码映射产生的影响

3. 版本选择：建议关注项目更新，及时升级到包含此修复的版本。

这个案例展示了编译器底层组件之间微妙的交互关系，也提醒我们在性能优化和功能开发过程中需要全面考虑各种配置组合的兼容性。