[!info] related notes

• 所属 MOC: TypeScript MOC
• 相关概念: TypeScript 中的 baseUrl 与 paths, TypeScript 语言服务与 tsserver
• 易混淆概念: VSCode 中的工作区 TypeScript 版本与内置 TypeScript 版本
• 相关资源: Vscode
• 关系笔记: TypeScript、tsc、tsconfig 与 tsserver 的关系

编辑器、TypeScript 版本与 tsconfig 诊断结果的关系

范围

这篇笔记解释的是“为什么同一份 tsconfig.json 在不同编辑器里会看到不同诊断”，而不是单独讲某个选项本身的语义。

为什么要放在一起理解

当用户看到：

• VSCode 报 baseUrl 已弃用
• Anti 不报

很容易先怀疑“是不是 VSCode 误报”。
但更常见的真实原因是：两边根本没有使用同一套 TypeScript 语言服务上下文。

依赖路径 / 调用链 / 演进链

理解这个问题，通常要按四层看：

1. tsconfig 里这个选项本身到底做什么
2. 当前编辑器用的是哪一版 TypeScript
3. 编辑器是如何接入 TypeScript 语言服务的
4. 项目命令行构建又是用哪一版 TypeScript

只要这四层里有一层不同，就可能看到不同的提示。

对比与易混淆点

本次案例的更合理解释

本次案例中，VSCode 菜单显示选中的是内置 TypeScript 6.0.3，而项目工作区版本是 5.9.3。

结合 TypeScript 官方文档，可以得到更稳妥的解释：

• TypeScript 6.0 已把 baseUrl 标记为 deprecated
• ignoreDeprecations: "6.0" 只能静默提示
• 如果编辑器正在使用 6.0.3，它就会先提示这个弃用项

因此：

• VSCode 报提示，并不奇怪
• 如果 Anti 使用的是更旧的 TypeScript，或者没有走同一套完整 tsserver 诊断路径，不报也不奇怪

这里关于 Anti 的判断是基于现象做的推断，不是已经验证过 Anti 内部实现。

为什么“同一文件”不等于“同一结果”

“同一文件”只是磁盘内容相同，不代表以下条件也相同：

• TypeScript 版本相同
• 项目边界相同
• tsconfig 解析方式相同
• 语言服务插件相同

所以真正需要对齐的是“分析上下文”，不是只盯着文件文本。

这类问题的排查顺序

遇到编辑器差异时，优先按这个顺序排查：

1. 看 VSCode 当前使用的是内置版还是工作区版
2. 运行 pnpm exec tsc -v 或等价命令，确认项目本地版本
3. 看另一编辑器是否有独立的 TS 版本或不同的校验器
4. 再决定是升级、切换版本，还是临时静默弃用提示

这次 baseUrl 案例的落地建议

短期：

• 如果要和项目构建保持一致，VSCode 切到工作区 TypeScript 更稳
• 如果只是想消除提示，可加 ignoreDeprecations: "6.0"

长期：

• 如果 baseUrl 只是给 paths 提供公共前缀，优先迁移掉 baseUrl
• 把 paths 写成相对 tsconfig 的显式路径
• 确认运行时和 bundler 也支持同样的 alias

参考信息

• TypeScript 6.0 Release Notes: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-6-0.html
• TypeScript TSConfig baseUrl: https://www.typescriptlang.org/tsconfig/baseUrl.html
• VS Code TypeScript compiling: https://code.visualstudio.com/docs/typescript/typescript-compiling