Biome 与 Vercel 合作，改进类型推断

Apr 2, 2025 - 7 min read

Arend van Beelen jr.

早在 2024 年初，Biome 就为其 roadmap 添加了一个雄心勃勃的目标：将 TypeScript 类型系统的一个子集直接集成到 Biome 中，以便类型相关的 lint 规则可以开箱即用。

¥Back at the start of 2024, Biome added an ambitious goal to its roadmap: integrate a subset of the TypeScript type system directly into Biome so that type-informed lint rules can work out of the box.

为了实现这一点，我们首先需要更好的基础设施。主要障碍是多文件分析，该功能将在 Biome 2.0 中推出。

¥In order to make this feasible, we first needed better infrastructure. The main blocker for this was multi-file analysis, which is coming with Biome 2.0.

今天，我们终于拥有了实现这一目标的技术手段，但作为一个项目，我们需要的不仅仅是技术手段。因此，我们非常荣幸地宣布 Vercel 成为我们的合作伙伴，帮助我们实现这一目标，并推动 Web 技术的发展。

¥Today, we finally have the technical means to implement this goal, but, as a project, we need more than only technical means. Which is why we are grateful to announce Vercel as a partner to help us achieve this goal and push the web forward.

Vercel 成为 Biome 的首个白金赞助商

¥Vercel becomes Biome’s first platinum sponsor

Vercel 已聘请我（Biome 的首席开发者之一）参与类型推断工作数月。Vercel 此次合作的目标是，一方面帮助改进其内部代码检查工具的用户体验（他们最近已将 Biome 标准化），另一方面与 JavaScript 生态系统的其他成员分享这些改进。

¥Vercel has contracted me (one of the Biome lead developers) to work on our type inference effort for many months. Vercel’s goal with this partnership is to both help improve their own internal linter DX (as they have recently standardized on Biome) and share those improvements with the rest of the JavaScript ecosystem.

我们的目标是提供功能齐全的 noFloatingPromises 规则的 (*) 版本以及类似的 noMisusedPromises 规则。

¥We aim to have a fully functioning(*) versions of the noFloatingPromises rule and a similar noMisusedPromises rule.

常见问题解答

¥Frequently Asked Questions

由于类型推断和类型检查器是我们社区的热门话题，我收集了一些关于此主题的常见问题。

¥Because type inference and type checkers are popular topics in our community, I have collected a few common questions on this topic.

你是否正在 Biome 中重新实现类型检查器？

¥Are you reimplementing a type checker in Biome?

否。TypeScript 的 tsc 是一个复杂且功能齐全的类型检查器，我们目前没有重构它的计划。类型检查仍需使用 tsc 文件。

¥No. TypeScript’s tsc is a complex and fully-featured type checker, and we have no intention to rebuild it. For type checking you are expected to continue to use tsc.

这项工作侧重于类型推断，这只是完整类型检查器功能的一小部分。目标是能够编写基于类型信息的 lint 规则，而无需证明该类型信息的正确性。

¥This work focuses on type inference which is a small subset of the functionality of a full type checker. The goal is to be able to write lint rules that act on type information, without needing to prove that this type information is correct.

如果你不知道类型信息是否正确，如何编写类型相关的 lint 规则？

¥How can you write a type-informed lint rule if you don’t know the type information is correct?

Lint 工具与类型检查器的目标不同。类型检查器旨在检测类型的误用，而代码检查器旨在检测常见的错误。但是，检测常见错误的目标并不要求其操作的类型必须 100% 正确。实际上，即使是 TypeScript 设计目标 也表示他们愿意为了提高效率而牺牲一些正确性。

¥Linters have different aims than type checkers. Where a type checker aims to detect misuse of types, a linter aims to detect common mistakes in general. But the goal of detecting common mistakes doesn’t require 100% correctness when it comes to the types it operates on. In fact, even the TypeScript Design Goals state they are willing to compromise correctness in favor of productivity.

对于代码检查工具来说，最重要的是避免误报，即代码检查规则可能错误地认为存在问题，而实际上并不存在。误报会令开发者感到沮丧，因为分析误报需要时间；浪费了时间，结果发现一开始根本没有问题。

¥For a linter, what’s most important is that we don’t flag false positives, instances where our lint rules may think there’s an issue when really there’s not. False positives are a source of frustration for developers, because they take time to analyze; time that was wasted when it turns out there really wasn’t an issue to begin with.

另一方面，漏报的问题较小。它们代表我们希望 lint 规则标记问题但未标记的情况。它们也可能导致生产力损失（因为没有在管道早期标记问题），但这并非规则本身造成的生产力损失。

¥On the other hand, false negatives are less problematic. They represent situations where we wish the lint rule would flag an issue, but didn’t. They can also represent lost productivity (by not flagging the issue early in the pipeline), but they are not productivity lost due to the rule itself.

假设一条 lint 规则没有误报，但有 20% 的漏报，它仍然能提供始终正确的规则 80% 的价值。所以我们的目标很简单：创建 lint 规则，避免误报，同时尽可能减少漏报。

¥Hypothetically, a lint rule that has no false positives, but has 20% false negatives, still offers 80% of the value of a rule that is always correct. So our goal is simply: Create lint rules that don’t flag false positives, while trying to get the amount of false negatives down as much as we can.

我们目前无法确定最终能达到多少百分比，但由于 Vercel 赞助了这项工作，我们将以他们的代码库为基准，并尝试针对他们的用例进行优化。

¥We cannot say upfront which percentage we will actually achieve, but since Vercel is sponsoring this work, we’ll use their repositories as a benchmark and try to optimise towards their use cases.

微软宣布将 tsc 移植到 Go 语言，这对你的工作有何影响？

¥How does Microsoft’s announcement of a Go port for tsc influence your work?

现在下结论还为时过早。Go 移植版尚未向用户开放，其他工具可以使用的 API 预计要到年底才能推出。此外，尽管 Go 移植版据称比 Node.js 版本快得多，但由于进程间通信以及需要在单独的进程中执行重复工作（例如解析文件），它仍然可能比 Biome 核心内置的实现慢得多。

¥It’s too early to tell. The Go port is not available to users yet, and the APIs that should allow it to be used by other tooling aren’t expected until the end of the year. Additionally, even though the Go port is supposedly much faster than the Node.js version, it will likely still be significantly slower than an implementation built into Biome’s core due to inter-process communication and the need to do duplicate work such as parsing files in separate processes.

目前，这让我们有机会开发自己的类型推断实现，并观察其效果。当 Go 版本可用于集成到其他工具时，我们可以重新评估我们的方法。

¥For now, that gives us an opportunity to pursue our own type inference implementation and see how it goes. When the Go version is available for integration into other tools, we can always reevaluate our approach.

我们可以关注你的开发进度吗？

¥Can we follow your progress?

是的！这里有一个公开的项目概览供大家查看：https://github.com/orgs/biomejs/projects/4/views/2

¥Yes! There’s a public project overview that people can inspect: https://github.com/orgs/biomejs/projects/4/views/2

请注意，由于会不断出现误报，因此项目中可能会持续添加问题。

¥Note that issues may be continuously added to the project as false negatives keep popping up.

VS Code 扩展 V3

Biome v2.0 测试版