cosmiconfig 读取 TS 配置报 findConfigFile is not a function

升级 TypeScript 7.0.2 后，工具还没开始检查业务源码，读取 .config.ts 就报 typescript.findConfigFile is not a function。如果堆栈落在 cosmiconfig 的 TypeScript loader，应先核对加载器使用的是哪一代 TypeScript API。

旧 loader 会导入 typescript，调用 findConfigFile、readConfigFile 和 transpileModule，再执行临时生成的配置。正式 TypeScript 7.0.2 的包入口已不是旧版 JavaScript Compiler API；新编译器能运行 tsc，不代表它仍向旧加载器提供同名函数。给 tsconfig 增加 paths、安装更多 @types，不能补出这个方法。

先找到真正加载配置的依赖

记录完整堆栈、配置文件绝对路径、实际运行 Node 版本，以及调用方解析到的 cosmiconfig 和 typescript。格式化工具、发布工具或工作区子项目可能带自己的依赖副本，不能只看根目录版本。

若栈中没有旧 loadTs、loadTsSync 或 resolveTsConfig，而是其他工具直接调用 TypeScript API，就应按那个工具的兼容范围处理。这里的方案针对配置加载阶段，不适合修复所有 findConfigFile 报错。

也不应直接从 typescript 的未公开内部路径导入旧函数。原生编译器与旧 API 之间不是换一个 exports 路径就能兼容的关系，临时补一个空函数还可能让配置以错误选项继续执行。

正式 cosmiconfig 10 改用 Node 加载

cosmiconfig 10.0.0 已正式移除这条对 typescript 包的依赖，改用 Node 的类型剥离加载配置；10.0.1 保留相同方向。升级前先满足其运行时要求：Node ^22.18 || >=24。Node 20 或较早的 22.x 不能只因为支持部分 TypeScript 功能，就视为符合这个包的要求。

如果配置加载由另一个工具内部创建，应优先升级那个工具到兼容版本。单在顶层安装 cosmiconfig 10，并不能保证它内部的旧副本会被替换；跨大版本强行覆盖也可能改变工具预期的搜索与加载行为。

类型剥离不等于按 tsconfig 完整转译。带运行时代码的 enum、namespace，以及依赖 tsconfig paths 的导入，都需要重新核对；只使用可擦除类型的配置才适合直接走这条轻量路径。不能为了让加载通过就开启一组全局实验选项，改变所有子进程的执行方式。

暂不能迁移时，提供等价的 JavaScript 配置

工具支持 .cjs 配置时，可以把这一份配置明确迁移为普通 CommonJS，去掉仅用于类型检查的写法，同时保留配置值和必要逻辑。例如原工具搜索 mytool.config.* 时：

// mytool.config.cjs
module.exports = {
  enabled: true,
  output: './dist',
};

这是独立示例，文件名和字段需要按原工具的协议填写，不表示所有工具都搜索这个名字。真实配置若导入了项目其他 TS 文件，仅改入口扩展名还不够，应把依赖链也交给已有且兼容的构建流程。

删除或停用旧 TS 配置前保留原件，确认工具实际选中了新文件。多个可搜索配置同时存在时，搜索顺序可能让旧文件继续优先；不要留下两份不同内容、再只看其中一份修改。

从原来失败的工具入口验证配置身份与最终值，随后运行该工具原有任务。能找到配置文件、成功加载配置，以及后续业务检查通过，是三个独立结果。修复加载兼容性时，应保留项目原有的编译器检查和错误退出规则。