让 TypeScript 工具更安全、更智能

Source: Dev.to

Overview

在过去的几周里，我专注于对真实 TypeScript 开发者日常工作产生影响的开源贡献，处理的议题超出了简单的样式修复。我参与了两个项目：

• typescript-eslint – 一套 ESLint 规则，用于保持 TypeScript 代码的安全性和一致性。
• publicodes/language-server – 一个 VS Code 扩展，为 Publicodes 语言提供语言服务器功能（诊断、补全、悬停、跳转到定义）。

这些贡献让我既能编写静态分析规则，又能实际参与语言服务器的实现。

typescript‑eslint contribution

我实现了 no-unsafe-* 规则的一个功能请求，使其能够检测对象类型内部的 unsafe any 值，而不仅仅是顶层的 any。

• 现有规则（no-unsafe-argument、no-unsafe-assignment 等）已经阻止了显而易见的情况，例如参数或变量直接被标记为 any，或整个泛型类型使用了 any。
• 问题在于，嵌套的 any 属性可能在更严格的对象类型中悄然出现而不触发警告。
• 我更新了这些规则使用的内部帮助函数，使其现在能够遍历对象、数组以及其他容器，以发现隐藏的 unsafe any。
• 添加了测试，确认 issue 中的确切示例现在会被报告，而安全的写法仍然通过。
• 清理了在更严格检查下开始出现失败的仓库部分。

publicodes language‑server contribution

我为单个工作区内的多模型提供了支持。

• 语言服务器将 Publicodes 语言集成到 VS Code 等编辑器中，为 .publicodes 文件提供语义高亮、诊断和跳转到定义等功能。
• 之前，服务器把工作区内所有 .publicodes 文件都视为属于一个巨大的模型，这在 monorepo 或多文件夹工作区中会导致问题，因为不同模型本应保持相互独立。
• 我的修复引入了 模型边界（例如最近的 package.json 或 .publicodes.config 文件），并按该边界对文件进行分组。
• 每个分组拥有自己的内部数据结构和引擎实例，因此文件的诊断、悬停、补全和定义现在会通过拥有该文件的模型，而不是全局模型。

Process and Reflections

工作是逐步进行的：

• 我花了大量时间阅读不熟悉的代码，理解各部分是如何协同工作的。
• 在 typescript-eslint 中，我先熟悉类型工具，然后编写代码，反复运行测试套件，并在出现新错误时进行调整。
• 在语言服务器中，我追踪文件发现、规则存储和诊断生成的流程，然后小心地将新的模型信息贯穿这些路径。
• 将工作拆分为更小的步骤（先跟踪模型，再更新解析，随后更新验证）被证明是关键。

回顾过去，我实现了最初的目标：

• 仍然专注于 TypeScript 工具链领域。
• 接手了略高于自己舒适区的任务，并在复杂逻辑中坚持下来。
• 认识到挑选过于复杂的问题会导致思考过度和卡住，但总体上提升了在严肃开源项目中贡献的信心。

Future Work

• 改进贡献计划，为审查和打磨预留更多时间。
• 继续推动自己在 TypeScript 生态系统中做出真实、有价值的贡献。