Biome's Missing ESLint Rule: A Community Voting Guide for padding-line-between-statements

Recently, a developer put out a call on Reddit, hoping the community would rally to add a commonly-used rule currently missing from Biome.js—Padding Line Between Statements. This rule is well known in the ESLint ecosystem and is used to enforce blank lines between logical groups of statements, thereby improving code readability. As a rapidly rising all-in-one frontend toolchain, Biome still has several gaps in its feature coverage, and this community vote is a microcosm of the effort to push the ecosystem toward completeness.

Background: What is Biome.js? Biome.js (formerly Rome Tools) is an all-in-one frontend toolchain project originally initiated by Babel's original author Sebastian McKenzie and later revived by the community. Its core is written in Rust, integrating code formatting, lint checking, import sorting, and other features into a single binary, executing 10–100 times faster than the ESLint + Prettier combination. Biome officially forked from Rome and became independent in 2023, and received an interoperability grant awarded by the Prettier team. It is regarded as an important representative of the new generation of frontend toolchains.

What is Padding Line Between Statements

padding-line-between-statements is a popular stylistic rule in ESLint. Its core function is to enforce or forbid blank lines between statements based on the types of the preceding and following statements. Compared to the crude approach of "blank lines between all statements," it offers fine-grained control, allowing developers to precisely define formatting style according to team conventions.

Since Nicholas C. Zakas created ESLint in 2013, it has accumulated thousands of rules and plugins thanks to its highly pluggable architecture. As of 2024, ESLint has over 300 core rules, and there are more than 5,000 plugin packages on npm prefixed with eslint-plugin-. padding-line-between-statements was first introduced as a core rule in ESLint v4.0, unifying several previously scattered standalone rules—for example, rules like newline-after-var and newline-before-return that existed independently in earlier versions were all consolidated into this more expressive unified rule. This kind of "merge and refactor" embodies ESLint's design philosophy of being "composable and configurable," and has led to the rule's widespread adoption in large TypeScript projects: it is often used together with the @typescript-eslint plugin to impose precise formatting constraints on TS-specific structures such as class members and interface declarations, making it one of the most frequently seen configuration items in enterprise-level frontend standards.

The Underlying Implementation Principle: AST Traversal

The lint rules of both ESLint and Biome are essentially about traversing and pattern-matching the AST (Abstract Syntax Tree). The AST is a tree-structured representation of source code, where each node corresponds to a syntactic element (variable declaration, function call, return statement, etc.). In ESLint, the padding-line-between-statements rule determines whether a blank line exists by checking the token spacing (line number difference) between adjacent nodes. In Biome, because the underlying implementation uses a custom CST (Concrete Syntax Tree) written in Rust, the rule API is fundamentally different from ESLint's and cannot be directly ported—the node traversal logic must be reimplemented from scratch based on Biome's rome_js_syntax crate, fully covering all the statement type matching scenarios and edge cases of the original rule. This is precisely the root cause of why the cost of porting each rule far exceeds "intuitive estimation."

Here's an intuitive example:

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

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

  bar();
}

In the second snippet, the variable declaration and the function call are separated by a blank line, making the logical grouping clearer. As the code grows in size, this visual "breathing room" can significantly reduce reading fatigue.

How the Rule Is Configured

The rule is quite flexible to configure, using a set of rule objects to describe "under what circumstances a blank line is needed." Each object contains three key fields:

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

Here, blankLine can be always (blank line required), never (blank line forbidden), or any (no restriction); prev and next are used to match statement types, such as return, var, const, block-like, etc. Developers can stack multiple rules to build a complete formatting strategy that conforms to team conventions, meeting common needs such as "a blank line is required before all return statements" or "no blank line between consecutive imports."

Why Biome Users Urgently Need This Rule

Biome positions itself as a high-performance toolchain that integrates linter and formatter, delivering execution speeds far surpassing the ESLint + Prettier combination thanks to its Rust-based core. However, a lead in speed does not mean complete rule coverage. For teams migrating from ESLint, the "equivalent replacement" of rules is the key to a smooth transition.

The wave of rewriting frontend toolchains in Rust (Biome, Oxc, SWC, Rolldown, etc.) is essentially about using the technical advantages of a systems programming language to replace the inherent limitations of the JavaScript runtime. Rust's ownership model guarantees memory safety without requiring garbage collection, making it excellent at concurrently parsing large codebases; zero-cost abstractions allow high-level language features without runtime overhead; and native multithreading capabilities allow Biome to process multi-file lint tasks in parallel. In contrast, Node.js's single-threaded event loop has a natural bottleneck in CPU-intensive AST parsing scenarios.

The Rust Frontend Toolchain Landscape: More Than Just Biome

Beyond Biome, the wave of rewriting frontend toolchains in Rust covers several important projects: Oxc (Oxidation Compiler) focuses on ultra-fast JavaScript/TypeScript parsing and linting, led by ByteDance engineers, and currently covers over 200 ESLint rules; SWC, as a Rust replacement for Babel, has already been integrated by default in Next.js; Rolldown is a Rust version of Rollup led by the Vite team, aiming to become the next-generation bundling core. These projects together form the "Rust frontend toolchain" ecosystem, but they also face the same cold-start dilemma. Notably, Oxc adopts a rule-coverage strategy different from Biome's—prioritizing a complete mirror of ESLint core rules to reduce migration friction, whereas Biome focuses more on first perfecting the formatting and core lint experience before gradually expanding stylistic rules. The two paths reflect their differing judgments on "user migration priority."

However, Rust toolchains face a cold-start dilemma in rule porting: the rule library that the ESLint community has spent a decade polishing must be reimplemented from scratch using Rust AST APIs. Each rule must handle edge cases and TypeScript semantics, and the engineering effort is not to be underestimated. This also explains why feature coverage has become a core sticking point in whether a new tool can be adopted at scale by enterprise teams.

Currently, Biome has not yet implemented padding-line-between-statements, which means teams that rely on it to unify code style will encounter a feature gap during migration. The poster noted that this rule "makes the codebase look less cluttered and easier to scan and read," which is especially important for the maintainability of large projects.

From Community Voting to Feature Delivery

This call reflects a common logic for advancing features in open-source tools: the visibility of community demand directly influences development priority. Biome uses the number of reactions on GitHub Issues as a signal for feature priority, which is a common practice among many active open-source projects—similar mechanisms are seen in projects like VS Code, the TypeScript compiler, and the Rust language. The VS Code team has publicly stated that the number of upvotes is a factor in its roadmap decisions, and the TypeScript team likewise incorporates reaction counts into its feature evaluation system.

It's worth noting that this "democratized" prioritization mechanism has its limitations: the demands of vocal individual developer communities may be over-amplified, while the critical needs of silent enterprise users can easily be underestimated.

A Multidimensional Priority Framework for Open-Source Governance

Mature open-source projects usually do not rely solely on reaction counts, but instead introduce an "impact matrix" for comprehensive evaluation: number of affected users (vote count) × severity of use case (quality of issue comments and concrete examples) × implementation complexity (engineering cost estimate). The Biome maintenance team also references industry survey data such as State of JS, along with direct feedback from enterprise users collected through sponsorship or Discord direct messages. This multidimensional evaluation can, to some extent, compensate for the neglect of long-tail demands caused by "democratic voting," and it is also a key aspect regulated in the project governance charters of open-source foundations such as the Linux Foundation and the Apache Foundation. For a rule like padding-line-between-statements that spans both individual developers and enterprise teams as audiences, its actual scope of impact is often far broader than the reaction count suggests.

Therefore, the poster encourages developers who use Biome and consider the rule valuable to go to the corresponding issue and vote in support—"every bit of community support can push a feature forward." For users, the cost of a single upvote is extremely low, yet it can substantively influence the tool's direction of evolution, making it one of the lowest-cost and most effective ways to participate in open-source governance.

Implications for the Frontend Toolchain Ecosystem

Behind this small matter lies the generational shift the frontend toolchain is undergoing. ESLint and Prettier, as de facto standards, have accumulated a vast ecosystem of rules and plugins, while a new generation of Rust tools like Biome and Oxc use performance as their breakthrough, attempting to reshape this landscape.

The challenge for new tools has never been merely "running faster," but whether they can catch up in feature completeness. Stylistic rules may seem trivial, but they are the foundational infrastructure that countless teams rely on daily. The absence of rules like padding-line-between-statements is precisely the "long tail" that inevitably needs to be filled during the transition between old and new tools. Behind every "tiny" rule often lies engineering wisdom and team conventions accumulated in specific coding scenarios, and the cost of porting far exceeds the technical implementation itself—it also involves a complete understanding of the semantic boundaries of the original rule and test coverage, including the correct handling of TypeScript-specific syntactic structures (decorators, enum declarations, type assertion blocks, etc.), as well as coordinating potential rule conflicts with the formatter.

For teams evaluating whether to migrate to Biome, it is recommended to first sort out the list of rules actually enabled in the existing ESLint configuration before making a decision, and compare them one by one against Biome's support. The Biome website provides a comparison table with ESLint rules, which can serve as a starting point for migration evaluation. For rules that are indeed missing but important, rather than passively waiting, it is better to actively participate in community feedback—as this vote demonstrates, the voices of users are an important driving force in the evolution of open-source tools.

Summary

The absence of a single formatting rule may seem insignificant, but it is a genuine facet for measuring the maturity of a toolchain. If Biome can fill in high-frequency rules like padding-line-between-statements, it will further lower the barrier to migrating from ESLint. And this community voting call reminds us once again: the improvement of the open-source ecosystem cannot happen without the ongoing participation of every user.