ESLint padding-line-between-statements rule

[seahindeniz]

The details and needs are explained on the relevant pages.

https://eslint.org/docs/latest/rules/padding-line-between-statements
https://eslint.style/rules/js/padding-line-between-statements

[arendjr]

We don’t implement stylistic rules in the linter. Instead, we rely on the formatter for which we follow Prettier rules.

[seahindeniz]

I’m sorry I didn't understand the explanation, how is Prettier relevant to this thread?
And just to confirm, is Prettier a sub dependency?

[arendjr]

Biome is a replacement for both ESLint and Prettier, so while it doesn't depend on Prettier, it does follow Prettier's philosophy and rules for all things formatting-related.

Because of this, we've made the decision to not implement any of ESLint's formatting rules, since that would conflict with the formatter and its philosophy.

[seahindeniz]

I see, thank you. That's a bit sad decision, to be honest 😕

Me and the groups I work with, find Prettier not DX friendly due to lack of implementations that increase the readability of code. Such as this thread and the logical operator placement. I hope you and your team reconsider the decision

[sonhavietnamese]

I want that too!!!!1

[ghost]

@arendjr Is there a similar formatting option for the "padding-line-between-statements" rule in the formatter?

Links for reference
https://eslint.style/rules/js/padding-line-between-statements

[fregante]

@ematipico I'm not sure I follow this logic. Biome has a formatter (like Prettier) and a linter (like ESLint). The latter already has a very long list of stylistic rules, how is this one different? https://biomejs.dev/linter/rules/#style

[dyc3]

We make a distinction between "style" and "formatting". "Formatting" generally pertains to how the code looks visually. You can format code differently and have it still parse as the same thing. "Style" generally points to code patterns.

For example:

if (foo) {
    bar();
}

is formatted differently than

if (foo) { bar(); }

but it is still the same code.

A good rule of thumb I use to determine if something is "style" or "formatting" is: does the change roughly produce the same AST when parsed? If so, its formatting. The reason we aren't implementing formatting rules from eslint is because we defer all formatting to be done by the formatter, which is aligned with Prettier.

[fregante]

I see. I hope however you can see past Prettier at some point and extend the formatting capabilities to be able to replace eslint.

[igarcez]

am I crazy to think that the asked for rule fit's the described definition of formatting instead of style since it produces the same AST, since the blank lines being enforced are ignored by the parsed?

[arendjr]

@igarcez no, you're not crazy ;)

We could indeed implement a paddingLineBetweenStatements option for the formatter. The problem is that, similar to Prettier, we follow a philosophy of not wanting to add more options to the formatter, since they have quite a significant impact on the maintainability of our codebase. We can make very rare exceptions to this. For instance, we once allowed an exception for accessibility reasons, but since we don't have the bandwidth to implement such options within the team, we did ask that someone volunteered to implement it. Then it never materialised...

So yeah, we could, but it would need to go through an RFC process, and there would need to be sufficient user demand, and someone willing to put in the work. Right now, I don't think that demand is there for an option such as this.