开启 TS 严格模式时，让 CI 只对新改动做增量检查，历史错误先挂账不爆仓
在 CI 中对 git diff 结果运行 tsc --strict，实现新代码从第一天起严格模式，历史错误通过 @ts-expect-error 挂账清单管理。方案包括：用 tsconfig.strict.json 覆盖主配置、仅对增量文件检查、生成欠账报告、处理依赖闭包误报、配合 ESLint 规则，以及按模块推进销账。已在两个存量项目验证，有效阻止新隐式 any 和空值风险，同时不阻塞 CI。
标签: #TypeScript
共 5 篇文章
esbuild 编译 TypeScript 时，装饰器和类型注解能走到哪一步，哪些场景必须回头用 Babel
esbuild 对 TypeScript 装饰器仅支持 TC39 Stage 3 新语法，旧版实验性装饰器语义残缺，尤其完全不支持 `emitDecoratorMetadata`，参数装饰器编译顺序也与 tsc 有差异；类型注解只做剥离、不做检查，`const enum` 不内联。NestJS、TypeORM 等依赖元数据的框架必须回退 Babel 或 tsc，纯类型擦除场景则可完全替代。
TypeScript 类型系统能装下量子纠缠的非局域性吗？我在前端模拟中碰到的三个硬骨头
TypeScript 类型系统无法在编译时捕获量子纠缠的非局域性，因为类型运算是局域的纯函数，而纠缠性质依赖运行时全局状态。文章剖析了三个根本限制：张量积类型无法静态区分乘积态与纠缠态，测量坍缩破坏引用透明性且类型无法表达因果链，浮点精度漂移导致类型标签失真。最终方案是让类型系统负责维度校验等静态约束，将物理行为验证交给运行时测试。
用 TypeScript 类型做接口文档，怎么让它跟后端返回保持同步
解决前后端接口类型不一致的核心方案：将 TypeScript 类型定义作为唯一真相来源，通过工具链实现自动化校验。具体做法是用 ts-json-schema-generator 将类型编译为 JSON Schema，再在 CI 中用 Ajv 校验实际响应数据。也可从后端代码直接生成前端类型，或用 OpenAPI 作为中间契约，配合 openapi-diff 检测破坏性变更。针对泛型、联合类型等复杂场景需注意工具版本和配置优化。
我们给组件 API 加了版本号，结果三年没出过 breaking change
组件库通过给每个 prop 标注语义化版本号，在类型层面实现了细粒度的契约管理。这套机制让 API 变更变得可见、可讨论，三年间在 200 多个组件的迭代中实现了零 breaking change，仅需付出少量类型定义和维护成本。