denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
95.98k stars 5.31k forks source link

fmt option to allow consecutive blank lines #26208

Open csvn opened 2 days ago

csvn commented 2 days ago

I know this issue may be closed, since Deno seems to have a similar opinionated philosophy as Prettier, but I'll give it a try since I could not find any docs discouraging feature requests for the formatter.

We have large amounts of code that often uses more than 1 blank line for separating content. Adding two instead of one blank line helps group content together visually (like having paragraphs in a book). They are not everywhere, but to our team they help improve readability of the code.

It would be awesome if there was a config option to allow multiple blank lines:

// deno.jsonc
{
  "fmt": {
    "maxConsecutiveLinebreaks": 2
  }
}

I agree with having great defaults for code formatting, but less flexibility also blocks adoption. This would be one of bigger blockers for formatting our code currently.

dsherret commented 2 days ago

I think this is too specific of a feature to be in deno fmt.

We have large amounts of code that often uses more than 1 blank line for separating content. Adding two instead of one blank line helps group content together visually (like having paragraphs in a book). They are not everywhere, but to our team they help improve readability of the code.

It might be better to use a comment or split up the code into smaller functions.

csvn commented 2 days ago

It doesn't always make sense to e.g. split Angular components into smaller parts. Having more than one blank line is sometimes very helpful to group interfaces together visually. So far for Deno code, it's not a big issue, even if we prefer to have 2 lines separating imports from code in modules.

If it's not a feature you want to support in deno fmt, I understand. Oxc seems to intend to create a more flexible formatter, but it's not ready yet. All formatters we've tried so far are too opinionated, so we've stuck with ESLint + style rules.