TypeScript 编译器发布后：严格选项、声明文件与构建输出的检查方法

TypeScript 升级常先表现为新增类型错误，但真正需要判断的是：这些错误是在揭示既有缺陷，还是构建配置、声明文件或模块解析已经改变。类型检查通过也不等于 JavaScript 运行一致，因为转译目标、模块格式和打包器仍会参与最终行为。面对新编译器，建议先固定配置和依赖，再把诊断变化、生成声明与运行回归关联起来。具体选项含义和版本行为应以当前编译器文档为准。

保留一份可比较的配置快照

升级前后分别保存tsconfig的展开结果、编译器版本、输入文件清单和输出目录。重点观察strict相关选项、module及moduleResolution、target、lib、paths和类型声明入口。许多问题并非代码不能理解，而是解析路径改为指向另一份声明。对于多包仓库，还应确认每个包是否继承同一基础配置，避免根目录检查成功而发布包采用不同参数。

按诊断类别处理，而不是批量忽略

将新增错误分为可空性、索引访问、函数参数、泛型推断、模块导入和第三方声明几类。对业务边界，优先增加运行时检查或缩小类型；对不准确的第三方声明，可局部包装并写明预期输入输出。避免使用过宽的断言掩盖整段调用链，因为这种做法会让后续版本失去保护作用。对于序列化数据，应同时测试缺失字段、额外字段和旧格式，以确认类型收紧没有阻断必要兼容路径。

声明文件是库兼容的重要产物

发布库时，生成的声明文件值得和JavaScript输出一样被审阅。检查公开函数、导出类型、条件类型展开和子路径导出是否仍符合预期；再用一个独立的消费项目安装打包产物进行编译。只在源仓库中引用源码，容易漏掉包元数据、声明路径或导出映射问题。模块导入在不同运行环境的差异，可结合JavaScript 运行时差异：同一代码为何在不同环境表现不同理解。

构建链路必须覆盖打包器

TypeScript 的编译结果经常还会被打包、压缩或转换。候选版本应触发一次完整生产构建，并执行启动、动态导入、服务端渲染或脚本任务等关键路径。若输出模块格式变化，需验证测试运行器、浏览器环境和服务端加载方式是否一致。Deno 的权限和导入映射检查也提示我们：运行时规则与编译阶段规则需要分开验证，可参考Deno 运行时升级：权限、导入映射与部署任务的回归检查。

用最小矩阵避免遗漏常用环境

可在持续集成中保留旧编译器基线与候选版本各一组任务，同时选取主要运行时完成集成测试。将类型测试、声明消费测试和运行测试分别报告，失败时就不会混在一起。关于压缩组合数量的方法可参考持续集成矩阵设计：用有限任务覆盖版本组合，而将错误转化为稳定断言的方式可参考兼容性测试设计：把版本风险转成可观察的行为。

TypeScript 升级的价值不在于清空红线，而在于让类型配置、公开声明和实际运行产物保持同一份契约。分层记录差异，才能判断每个报错应修复、调整还是保留兼容处理。