迁移Jest测试至Vitest遇依赖导入错误，inline.deps与alias配置无效

针对你遇到的@package/dependency seems to be an ES Module but shipped in a CommonJS package错误，结合你之前Jest的解决方案，尝试以下步骤修复：

1. 同时配置全局与测试环境的别名，并排除包的自动依赖处理 #

Vitest的resolve.alias负责项目构建时的路径解析，test.alias专门作用于测试环境，同时需要排除该包的自动依赖处理，避免和别名规则冲突。修改Vitest配置文件：

export default defineConfig({
  resolve: {
    alias: {
      '@package/dependency': '@package/dependency/js'
    }
  },
  test: {
    globals: true,
    environment: "jsdom",
    setupFiles: "./src/setupTests.js",
    // 测试环境单独配置别名
    alias: {
      '@package/dependency': '@package/dependency/js'
    },
    // 禁止Vitest自动处理该包的依赖解析
    deps: {
      exclude: ['@package/dependency']
    }
  }
})

2. 同步TypeScript路径映射（若使用TS） #

如果你的tsconfig.json中配置了paths，需要保持和Vitest别名一致，确保TypeScript编译时能正确解析路径：

{
  "compilerOptions": {
    // 其他配置...
    "paths": {
      "@package/dependency": ["node_modules/@package/dependency/js"]
    }
  }
}

3. 手动指定包的转换规则（若上述方法无效） #

如果包的模块结构仍存在解析问题，可通过test.transform强制用esbuild转换该包的文件：

test: {
  // 原有配置...
  transform: {
    // 匹配该包下的JS文件，用esbuild处理
    '^@package/dependency/.+\\.js$': 'esbuild'
  }
}

为什么之前的方案无效？ #

• deps.inline仅将包内联到测试代码中，但无法解决包本身的模块入口路径问题；
• 单独配置resolve.alias或test.alias可能无法覆盖Vitest的测试环境解析逻辑；
• 若未排除该包的自动依赖处理，Vitest的内置依赖解析会优先于别名规则生效。

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