TypeScript 开发与迁移
一个包发生变化，下一个包也应能理解。
如果每个难处理的值最终都变成 any，构建通过也很难让人放心。我们改进现有 JavaScript 或 TypeScript 代码描述数据、提供接口和发现不兼容变更的方式，让类型改进保持明确范围，而不是演变成未经计划的重写。
直接回答
Wavect 为现有应用、库和软件包引入 TypeScript，并改进它们之间的类型契约。双方先约定哪些边界需要检查、外部数据如何验证，以及哪些部分不在迁移范围内。
适用情况
- 在现有 JavaScript 产品中逐步采用 TypeScript 的团队
- 共享类型已无法准确描述包之间实际传递数据的代码库
其他服务可能更合适
- 用户流程和架构尚未明确的新产品
- 没有跨模块类型问题的单个界面功能
从会影响其他产品模块的变更开始
声明类型并不会验证收到的响应
我们将外部输入与已经检查的内部表示分开。请求、已存储记录以及第三方响应进入应用时，需要明确的解析或验证。在边界内部，可区分的状态、空值处理和清晰的错误结果，帮助调用方作出预期决定。适合移除的误导性类型断言会被移除，剩余例外则会记录下来。仅仅共享一个接口，不能证明运行时的数据兼容。
按团队能持续维护的顺序增加检查
迁移计划先确定一个小型包或业务流程、它的调用方以及验收条件。JavaScript 与 TypeScript 可以在覆盖范围逐步扩大的过程中共存。我们先约定编译器设置、公开导出和构建检查，再扩大范围。TypeScript 迁移指南提供语言层面的参考；具体顺序由依赖和交付约束决定。大范围架构替换仍由遗留系统现代化承接。
SDK 更新能暴露响应格式的变化
示例验收场景：报价 API 增加一种结果状态。穷尽性检查在构建时指出哪个调用方尚未处理新分支；未知的外部响应则在运行时验证中被拒绝，并给出可用的诊断信息。原有受支持响应仍通过测试。双方先约定参与验证的调用方和版本发布顺序。这是建议的验收设计，不是已实现的客户成果，也不表示类型能发现所有缺陷。
让下一位贡献者也能遵循这些规则
交付包括修改的软件包、检查项、剩余类型缺口，以及扩展公开契约的示例。维护者可以看到哪些位置仍需要断言或生成类型。我们还会检查另一位开发者是否能在不削弱规则的情况下新增一种状态。请准备代码库、可复现的构建方式，以及目前引发歧义的数据脱敏示例。
开始前的常见问题
不必。可以从一个包或一条边界开始，让现有 JavaScript 继续留在同一交付计划中。范围说明会记录新增检查覆盖，以及明确暂不修改的部分。
不能。静态检查不能证明网络响应实际包含什么，也不能证明业务规则正确。运行时验证和行为测试仍是约定边界的一部分。
可以。编译器设置、导出的契约和包的职责，都可以在现有技术栈中改善。是否迁移框架需要单独决定。
不需要。相关契约可以位于一个代码库，也可以分布在多个包中。版本管理和调用方检查应适应团队实际发布软件的方式。
评估 TypeScript 边界
请说明哪些变更目前难以确认正确性：软件包、SDK、API 响应，还是 JavaScript 迁移。补充构建环境，以及必须保持可用的调用方。