Angular 中如何解决 NGXS 与 Vitest 的 TypeScript 编译冲突？

2026-11-06数据阿明

结论

不建议长期注释掉根配置中的 references。它会把应用和测试配置作为独立的 TypeScript 项目纳入项目结构。移除后，@Selector() 的错误可能会消失，但 spec 文件也会失去原有的配置入口。

现有信息没有提供具体的编译错误，也没有说明 NGXS 和 TypeScript 的版本，因此还不能判断 @Selector() 报错的根因。建议先恢复项目引用，再分别检查应用和测试配置，不要通过修改根配置来绕过单个错误。

恢复根配置中的项目引用

取消注释 files 和 references，保留 Angular 生成的项目结构：

{
  "files": [],
  "references": [
    {
      "path": "./tsconfig.app.json"
    },
    {
      "path": "./tsconfig.spec.json"
    }
  ]
}

确认 tsconfig.app.json 和 tsconfig.spec.json 都存在，并且各自的 extends 指向根 tsconfig.json。应用代码和测试代码应分别由对应的子配置编译。

检查 Vitest 的测试类型配置

检查 tsconfig.spec.json，确认它包含 spec 文件，并配置了与项目 Vitest 集成方式相符的类型。例如，项目通过 vitest/globals 使用全局测试 API 时，配置通常类似这样：

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "types": ["vitest/globals"]
  },
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}

如果 spec 文件通过导入 describe、it 等 API 使用 Vitest，而不依赖全局类型，就不要只为消除类型错误而盲目加入全局声明。还要检查测试配置是否包含 Jest 类型。测试运行器已经改为 Vitest 时，应避免同时加载不需要的 Jest 声明，以免测试 API 的类型发生冲突。具体配置应根据项目生成的 Angular 配置和 Vitest 集成方式确定。

单独定位装饰器错误

恢复引用后，分别运行项目已有的应用和测试类型检查或构建命令，确认错误来自 tsconfig.app.json 还是 tsconfig.spec.json。再根据完整诊断信息检查以下内容：

experimentalDecorators 是否在报错子项目的有效配置中设为 true。根配置虽然已启用该选项，子配置仍可能覆盖它。
TypeScript、Angular 和 NGXS 的版本组合是否兼容。不要只凭 @Selector() 报错就升级或降级某个包，应先查看错误位置和类型诊断，再核对这些依赖各自支持的版本范围。
是否有其他 TypeScript 配置或测试类型声明改变了装饰器的类型环境。

目前缺少错误文本，无法确定 @Selector() 的修复方法。如果恢复 references 后错误仍然存在，请提供完整编译诊断、typescript、Angular、NGXS 和 Vitest 的版本，以及相关的 selector 声明，以便进一步判断问题是否与版本兼容或代码类型有关。