Blank lines option

[spinlud]

Is possible to have an option to add blank line rule(s) in the formatter?
Eg transform this

class Temp {
    @Dec1
    prop1! int;
    @Dec2
    prop2! string;
}

to this:

class Temp {
    @Dec1
    prop1! int;

    @Dec2
    prop2! string;
}

or this:

class Temp {

    @Dec1
    prop1! int;

    @Dec2
    prop2! string;

}

[lazarljubenovic]

Relevant:

https://eslint.org/docs/rules/lines-between-class-members
https://eslint.org/docs/rules/padded-blocks

Might be of some help, since they both have fixes.

[dsherret]

Thanks @lazarljubenovic! I appreciate the "prior art" in order to get some ideas 🙂

Right now only member spacing is implemented for enum members. The options are "maintain", "newline", and "blankline" (I believe). I could add this to other nodes and make a general setting.

Also, I can add a "padding blocks" option. I'm just going to get dprint/dprint#54 merged before doing any of this though.

[kkoudev]

@dsherret Any update on this?

[B4nan]

Is this something you still consider? Is there anything we can help with to move it forward?

I think it would be a great way to attract many new users (like myself) who can't stand how prettier works when it comes to blank lines, but still want to use some formatter. The problem is especially visible when you use decorators, but it's not just about that. Here is a relevant prettier issue: prettier/prettier#4870, it's funny how they suggest using eslint instead if this bothers you, while the TS eslint version has completely broken indent rule, and they point in the very opposite direction - don't use our broken indent rule, use a formatter instead.

[lazarljubenovic]

I love coming to an issue and being greeting with my own comment 😄

Experimenting with dprint again; would love to see this option. Here's a list of my mental rules for formatting -- it might help decide on which options to add.

1. Obligatory exactly two blank lines after all imports. Allow at most one blank line between groups of imports.

import a from 'a'
import b from 'b'

import x from './x'
import y from './y'


console.log()

2. Inside blocks, allow at most one blank line between things.

function () {
  foo()
  bar()
}

3. If the block has at least one empty line, then padding empty lines are necessary.

function () {

  // first this
  foo()
  bar()

  // then this
  foo()
  bar()

}

That way, a simple class could be written as

class Foo {
  bar: string
  baz: number
}

but a more complex one would, due to blank lines between properties, force the padded lines.

class Foo {

  /** docs */
  bar: string

  /** docs */
  baz: string

}

Bonus points: anything multi-lined in a class forces blank lines around it (which in turn forces the padding.

I love the topic of formatting code. I probably sound crazy to some with the rules I follow, and yet I had to ask myself really hard to define how I format code manually (and subconsciously) to derive all the rules up there 🤔

[Bessonov]

I am currently experimenting with dprint, and it appears to be superior to many options I have tried so far, such as eslint, prettier, oxc, and biome. The "AST configuration" feature is particularly impressive. dprint is almost perfect and lacks only a few options, and this is one of them.

I largely agree with the proposal made by @lazarljubenovic in #7 (comment). However, I'm not entirely convinced by the two-blank lines part.

Additionally, I would like to suggest an option to preserve single empty lines and remove only redundant ones. With the AST configuration, this enhancement would make dprint even more powerful.

[Bessonov]

@lazarljubenovic for the two-blank lines part you are, probably, interested in #394

[Bessonov]

@dsherret after thinking about the two blank lines proposed earlier, I have come to the conclusion that the best option would be something like 'maintain' | number, where the number represents the count of line breaks. 0 would mean no line break, 1 would represent one line break, and so on. Together with the AST configuration, this would be quite powerful.

[bschaepper]

This project looks amazing, I'd use it over prettier/biome in a heartbeat once this feature is done.

[todor-a]

Is there a vision on how we want this to look like? I would love to give implementing it a go.

@dsherret