Biome缺失的ESLint规则：padding-line-between-statements社区投票指南

近日，一位开发者在 Reddit 上发起呼吁，希望社区为 Biome.js 添加一个目前缺失的常用规则——Padding Line Between Statements（语句间填充空行）。这一规则在 ESLint 生态中广为人知，用于强制在逻辑语句组之间插入空行，从而提升代码可读性。作为正在快速崛起的一体化前端工具链，Biome 在功能覆盖上仍存在若干空白，这次社区投票正是推动生态完善的一个缩影。

背景：Biome.js 是什么？ Biome.js（前身为 Rome Tools）是由 Babel 原作者 Sebastian McKenzie 发起、后经社区重启的一体化前端工具链项目。其核心用 Rust 编写，将代码格式化、lint 检查、导入排序等功能集成在单一二进制中，执行速度比 ESLint + Prettier 组合快 10–100 倍。Biome 于 2023 年正式从 Rome fork 独立，并获得 Prettier 官方颁发的互操作性奖金，被视为新一代前端工具链的重要代表。

什么是 Padding Line Between Statements

padding-line-between-statements 是 ESLint 中一个颇受欢迎的样式规则，核心作用是根据前后语句的类型，强制或禁止在它们之间插入空行。相比简单粗暴的「所有语句间都空行」，它提供了细粒度的控制能力，让开发者可以按团队规范精确定义排版风格。

ESLint 自 2013 年由 Nicholas C. Zakas 创建以来，凭借其高度可插拔的架构积累了数千条规则和插件。截至 2024 年，ESLint 核心规则超过 300 条，npm 上以 eslint-plugin- 为前缀的插件包超过 5000 个。padding-line-between-statements 最早在 ESLint v4.0 中作为核心规则引入，将原先分散的多条独立规则统一整合——例如早期版本中独立存在的 newline-after-var、newline-before-return 等规则，均被纳入这一更具表达力的统一规则中。这种「合并重构」体现了 ESLint「可组合、可配置」的设计哲学，也使得该规则在大型 TypeScript 项目中得到广泛采用：常与 @typescript-eslint 插件配合，对类成员、接口声明等 TS 特有结构施加精确的排版约束，是企业级前端规范中出镜率极高的配置项之一。

规则的底层实现原理：AST 遍历

ESLint 和 Biome 的 lint 规则本质上都是对 AST（Abstract Syntax Tree，抽象语法树）的遍历与模式匹配。AST 是源代码的树形结构表示，每个节点对应一个语法元素（变量声明、函数调用、返回语句等）。padding-line-between-statements 规则在 ESLint 中通过检查相邻节点之间的 token 间距（行号差值）来判断是否存在空行。在 Biome 中，由于底层使用 Rust 实现的自定义 CST（具体语法树，Concrete Syntax Tree），规则 API 与 ESLint 存在本质差异，无法直接移植——需要从头基于 Biome 的 rome_js_syntax crate 重新实现节点遍历逻辑，并完整覆盖原规则的所有语句类型匹配场景和边界用例。这正是每条规则移植成本远超「直觉估算」的根本原因。

举一个直观的例子：

// 不符合规范
function foo1() {
  var a = 0;
  bar();
}

// 符合规范
function foo1() {
  var a = 0;

  bar();
}

在第二段代码中，变量声明与函数调用之间被一个空行分隔，逻辑分组更清晰。当代码体量增大时，这种视觉上的「呼吸感」能显著降低阅读疲劳。

规则的配置方式

该规则配置相当灵活，通过一组规则对象描述「什么情况下需要空行」。每个对象包含三个关键字段：

// eslint.config.js
{
  "padding-line-between-statements": [
    "error",
    {
      "blankLine": LINEBREAK_TYPE,  // never / always / any
      "prev": STATEMENT_TYPE,        // 前一条语句类型
      "next": STATEMENT_TYPE         // 后一条语句类型
    }
    // ... 可叠加多条规则
  ]
}

其中 blankLine 可以是 always（必须空行）、never（禁止空行）或 any（不限制）；prev 和 next 用于匹配语句类型，例如 return、var、const、block-like 等。开发者可以叠加多条规则，构建出符合团队约定的完整排版策略，满足「所有 return 语句前必须空行」「连续 import 之间不空行」等常见需求。

为什么 Biome 用户迫切需要这条规则

Biome 定位为集 linter、formatter 于一体的高性能工具链，凭借 Rust 编写的底层带来了远超 ESLint + Prettier 组合的执行速度。然而，速度领先并不意味着规则覆盖完整。对于从 ESLint 迁移过来的团队而言，规则的「等价替换」是能否顺利切换的关键所在。

以 Rust 重写前端工具链（Biome、Oxc、SWC、Rolldown 等）的浪潮，本质上是在用系统级编程语言的技术优势替代 JavaScript 运行时的固有局限。Rust 的所有权模型保证了内存安全且无需垃圾回收，使其在并发解析大型代码库时表现出色；零成本抽象让高级语言特性不带运行时开销；原生多线程能力让 Biome 可以并行处理多文件 lint 任务。相比之下，Node.js 的单线程事件循环在 CPU 密集型的 AST 解析场景下存在天然瓶颈。

Rust 前端工具链全景：不止 Biome 一家

除 Biome 外，Rust 重写前端工具链的浪潮还涵盖多个重要项目：Oxc（Oxidation Compiler）专注于超高速 JavaScript/TypeScript 解析与 lint，由字节跳动工程师主导，目前已覆盖超过 200 条 ESLint 规则；SWC 作为 Babel 的 Rust 替代品已被 Next.js 默认集成；Rolldown 是 Vite 团队主导的 Rust 版 Rollup，目标是成为下一代打包核心。这些项目共同构成了「Rust 前端工具链」生态，但也面临同样的冷启动困境。值得注意的是，Oxc 采用了与 Biome 不同的规则覆盖策略——优先实现 ESLint 核心规则的完整镜像，以降低迁移摩擦，而 Biome 则更侧重先完善格式化与核心 lint 体验，再逐步扩展样式规则。两种路径反映了各自对「用户迁移优先级」的不同判断。

然而 Rust 工具链在规则移植上面临冷启动困境：ESLint 社区用十年时间打磨的规则库需要从零用 Rust AST API 重新实现，每条规则都要处理边界情况和 TypeScript 语义，工程量不可小觑。这也解释了为何功能覆盖度成为新工具能否被企业团队大规模采用的核心卡点。

目前 Biome 尚未实现 padding-line-between-statements，这意味着依赖它统一代码风格的团队在迁移时会遭遇功能缺口。发帖者指出，这一规则「能让代码库显得不那么杂乱，更易于扫描阅读」，对大型项目的可维护性尤为重要。

从社区投票到功能落地

这次呼吁反映了开源工具常见的功能推进逻辑：社区需求的可见度直接影响开发优先级。Biome 采用 GitHub Issue 的 reaction 数量作为功能优先级信号，这是许多活跃开源项目的通行做法——类似机制在 VS Code、TypeScript 编译器、Rust 语言等项目中均有体现。VS Code 团队公开表示 upvote 数量是其路线图决策的参考维度，TypeScript 团队同样将 reaction 数量纳入功能评估体系。

值得注意的是，这种「民主化」的优先级机制也有其局限性：高声量的个人开发者社区的需求可能被过度放大，而沉默的企业用户的关键诉求则容易被低估。

开源治理的多维优先级框架

成熟的开源项目通常不会单纯依赖 reaction 数量，而是引入「影响矩阵」进行综合评估：覆盖用户数量（投票数）× 使用场景严重程度（issue 评论质量与具体案例）× 实现复杂度（工程成本估算）。Biome 维护团队还会参考 State of JS 等行业调查数据，以及通过赞助或 Discord 私信渠道收集的企业用户直接反馈。这种多维评估能一定程度上弥补「民主投票」导致的长尾需求被忽视问题，也是 Linux 基金会、Apache 基金会等开源基金会在项目治理章程中重点规范的内容。对于 padding-line-between-statements 这类跨越个人开发者与企业团队两类受众的规则，其实际影响范围往往比 reaction 数量所呈现的更为广泛。

因此，发帖者鼓励正在使用 Biome 且认为该规则有价值的开发者，前往对应 issue 投票支持——「每一份社区支持都能推动功能向前」。对用户来说，一次点赞的成本极低，却能实质性地影响工具的演进方向，是参与开源治理成本最低、也最有效的方式之一。

对前端工具链生态的启示

这件小事背后，折射出前端工具链正在经历的代际更替。ESLint 与 Prettier 作为事实标准积累了海量规则和插件生态，而 Biome、Oxc 等新一代 Rust 工具则以性能为突破口，试图重构这一格局。

新工具的挑战从来不只是「跑得更快」，而是能否在功能完整度上追平前辈。样式规则看似琐碎，却是无数团队日常依赖的基础设施。padding-line-between-statements 这类规则的缺失，正是新旧工具交替过程中必然要填补的「长尾」。每一条「微小」规则背后，往往都沉淀着特定编码场景下的工程智慧和团队约定，其移植成本远不止于技术实现本身，更涉及对原规则语义边界的完整理解与测试覆盖——包括对 TypeScript 特有语法结构（装饰器、枚举声明、类型断言块等）的正确处理，以及与格式化器之间潜在的规则冲突协调。

对于正在评估是否迁移到 Biome 的团队，建议决策前先梳理现有 ESLint 配置中真正启用的规则清单，逐一比对 Biome 的支持情况。Biome 官网提供了与 ESLint 规则的对照表，可作为迁移评估的起点。对于确实缺失但重要的规则，与其被动等待，不如主动参与社区反馈——正如这次投票所展示的，用户的声音是开源工具进化的重要动力。

小结

一条排版规则的缺失，看似微不足道，却是衡量工具链成熟度的真实切面。Biome 若能补齐 padding-line-between-statements 这类高频规则，将进一步降低从 ESLint 迁移的门槛。而这次社区投票的呼吁，也再次提醒我们：开源生态的完善，离不开每一位使用者的持续参与。