Fri Jan 31 2025
...
FastComments TypeScript 迁移完成
! 本文包含技术术语
新变化
在 FastComments，我们重视静态类型语言。更具体来说，我喜欢编译器较快的良好类型系统。FastComments 开始时采用了后者——或者没有编译器。在第一年内，我们用现代 Java 编写了两个服务，但主要的后端和前端库是用运行在 Node 上的 CJS JS 编写的。
为了迎接下一个十年的发展，我们已将最大的 FastComments 组件迁移到 TypeScript。
这涉及到迁移超过 13 万行代码（其中 10 万行为后端），跨越 1441 个文件，并修复超过 8000 个编译错误。
这项工作在两周内完成。
代码冻结 - 感谢
我要感谢我们的客户在我们进行了为期两周的代码冻结以完成这项升级期间的 bug 修复或功能发布延迟。谢谢你们！
修复的错误
正如你所想象的，我们修复了一些错误。大多数与垃圾邮件检测和缓存相关。
重大变更
- 所有 API 端点现在返回状态：'failed'，而不是混合的“failed”和“failure”作为状态值。"success" 保持不变。
- 如果没有匹配，我们将不再默认使用第一个小部件配置，而是返回默认的系统配置。
这是什么体验？
我们发现，像往常一样，NPM 生态系统中许多帮助完成此任务的工具并没有很好地工作。因此，我们使用 LLM 生成脚本来完成许多工作。例如，我们大量使用 JSDoc，以便可以编写脚本将 JSDoc 转换为 TypeScript 接口和类型定义，并正确注释函数参数和返回类型。我们还使用这些脚本从 CJS 迁移到 ESM，这包括重写导入、导出，以及检测常见运行时问题，如 __dirname。
我提到过运行时问题吗？
2025 年的 TypeScript 怎么样？
TypeScript 是一种编写业务逻辑的不错语言。但 Java 的开发体验仍然更好。如果 Java、Go 或 Rust 编译，大概率可以运行。对于 TypeScript，我可以做这样的事情：
console.log(__dirname);
... 并且这将被编译。
但在使用现代 ES 模块时，它将无法运行。你的 IDE 很乐意自动完成功能 __dirname，然后在运行时就会出错。感觉就像 Spring DI，但更糟。
你还可以做这样的事情：
context.someImportantMethodToCall;
现在，这是一个“语句”。这是一个有效的“语句”。乍一看，你可能会认为我们正在调用 someImportantMethodToCall，但实际上并不是！至少我的 IDE 并没有对此发出警告，编译器也没有。代码将什么也不做（除非 someImportantMethodToCall 是一个类的 getter，在那种情况下它会被隐式调用...）
修复的方法是：
context.someImportantMethodToCall();
我认为你可能可以通过类似 eslint 的工具以及某种“不允许副作用”的规则来检测这一点，但那样你就要拉入另一大堆库以保持更新，然后 eslint 每次构建都必须解析你的整个代码库，工具变慢等等——不谢谢。处理像 eslint 这种慢工具的生产力影响，在我过去的工作中比我从 eslint 修复/预防的小问题中获得的生产力“提升”要显著得多。现在有更快的替代品出现，这非常好。
TypeScript 很好，因为有像 Pick<User, 'username', 'email'> 这样的语言特性。这结合类型推断，为大对象的子集提供了一种从数据库获取类型安全查询结果的方法，而无须为每种形状定义一个类。Pick 是我惊讶 Scala 没有的东西。类型联合也非常好。
增量构建也工作得相当好，我们在 CI 中的构建时间平均仅增加了 5 - 10 秒，用于构建共享库、前端和后端。
开发时间线
对于那些好奇的人，这里是我们的进展情况：
- 第一天：在 362 个文件中发现 5564 个错误。
- 第二天：在 239 个文件中发现 4034 个错误。
- 第三天：在 191 个文件中发现 3784 个错误。
- 第四天：在 169 个文件中发现 2974 个错误。
- 第五天：在 171 个文件中发现 3000 个错误。
- 第六天：在 165 个文件中发现 2916 个错误。
- 第七天：在 157 个文件中发现 2618 个错误。
- 第八天：在 109 个文件中发现 2253 个错误。
- 第九天：在 69 个文件中发现 1605 个错误。
- 第十天：在 53 个文件中发现 686 个错误。
- 第 11 天：后端单元测试通过
- 第 12 天：开始迁移前端，发现 3118 个错误。
- 第 13 天：发现 2172 个错误。
- 第 14 天：发现 1224 个错误。
- 第 15 天：发现 498 个错误。
- 第 16 天：所有编译错误已修复。
- 第 17 天：发布。E2E 测试通过。预计在意外运行时问题中停机 30 分钟。:)
未来
我们这样做是为了支持下一个十年的开发。系统现在足够庞大，以至于使用类型系统进行开发比没有类型系统更快。
你还可以期待我们在 NPM 上的 TypeScript 库得到改善，因为我们现在已经在服务器和客户端代码中使用该库。
我们也很快会直接从服务器代码发布生成的客户端 SDK，这是我们推动这项工作的主要动机之一。
总结
像所有重大版本发布一样，我们很高兴能够花时间优化、测试并正确发布这些更改。如果你发现任何问题，请在下方告诉我们。
干杯！