Rush Monorepo中Jest预设的jest.doMock模块解析路径问题

核心问题分析 #

你的问题在于Jest预设包中的setupFiles脚本运行时，模块解析的基准目录是预设包本身的目录，而非使用该预设的子包目录。同时由于循环依赖限制，无法将内部包添加为预设包的依赖。

解决方案：动态从子包目录解析内部模块 #

通过require.resolve（或ES模块的动态import结合require.resolve）指定解析路径为子包的工作目录，让Jest从使用预设的子包目录而非预设包目录查找内部模块。

方案代码实现 #

若使用CommonJS格式的setup文件：

// 从当前测试执行的子包目录解析internalPackageA
const { mockedFuncA } = require(require.resolve('<internalPackageA>', { paths: [process.cwd()] }));

// 同样从子包目录解析要Mock的internalPackage
const targetPackagePath = require.resolve('<internalPackage>', { paths: [process.cwd()] });

jest.doMock(targetPackagePath, () => ({
  funcA: mockedFuncA
}));

若使用ES模块格式的setup文件（需支持顶层await）：

// 动态解析并导入internalPackageA
const packageAPath = require.resolve('<internalPackageA>', { paths: [process.cwd()] });
const { mockedFuncA } = await import(packageAPath);

// 解析目标包路径
const targetPackagePath = require.resolve('<internalPackage>', { paths: [process.cwd()] });

jest.doMock(targetPackagePath, () => ({
  funcA: mockedFuncA
}));

原理说明 #

• require.resolve的paths参数指定了模块解析的起始目录，这里用process.cwd()获取当前运行Jest的子包目录（即使用预设的子包根目录）。
• 这种方式不需要将内部包添加到预设包的依赖中，完全避免了循环依赖问题。
• 所有使用该预设的子包无需额外配置，直接复用预设中的Mock逻辑。

额外注意事项 #

• 确保子包中已通过Rush正确链接了内部包，否则require.resolve无法找到对应的模块。
• 若使用ES模块，需确保Jest配置中启用了顶层await（可通过升级Jest版本或调整testEnvironmentOptions实现）。

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