A Better Formatter 😭

[babakfp]

Prettier is great, but it's not perfect. This is what I want from a code formatter that I expect it to be better than Prettier. This is just what I want, so, you may not like it, and that's fine.

A good out of the box experience with good defaults

Indentation size set to 4

Prettier has this option set to 2 by default, and as a result, so mane projects just use the default value. Well, this sucks because it's hard for me to read a code that is indented so little. It's hard to distinguish between the indentations, because the difference is a single white space.

Semicolons turned off

They are not required in JavaScript, so I don't need to have them. So, it's a preference to have them. If anyone prefers it, they can just turn on the option and get what they want.

A problem that I have with semicolons, is something similar to JSON code. JSON doesn't support trailing commas, so the last property must not have a comma. if you take the last property and move it up, you will get a syntax error as result. Now, you would need to add a comma to that property and remove the comma from the last property. This is not a good experience at all. In some scenarios, something similar happens when using semicolons too.

Better JSON parser for a better UX

As I explained above:

JSON doesn't support trailing commas, so the last property must not have a comma. if you take the last property and move it up, you will get a syntax error as result. Now, you would need to add a comma to that property and remove the comma from the last property. This is not a good experience at all.

So, I expect the code formatter to understand what is going on in these kinds of situations and just do what it's sposed to do. I don't want a syntax error, I just want it to work.

This isn't only about trailing and missing commas, it's also about missing quotes, using single quotes and etc. If the quotes are missing, just add them. If single quotes are used, just change them to double quotes. Prettier does a good job here.

Easy config options

One of the things I didn't like about Biome, was that, the config file had too much things going on in it.

Prettier

It may be seen like a bad idea to have a different API than Prettier, but what if Prettier changes their API after OXC formatter comes out, is OXC going to just follow what Prettier does? I think the goal should be better defaults.

(I saw a discussion about OXC being a drop-in replacement to Prettier, so that's why I added this text).

Built-in import/export sorter

There are so many prettier plugins for this, but some things are wrong with all of them.

prettier-plugin-organize-imports
@ianvs/prettier-plugin-sort-imports
@trivago/prettier-plugin-sort-imports
prettier-plugin-sort-imports

These are the plugins that I have tried, but none of them are perfect.

Build something the has many customization features.

Add all and any kind of customization options

A cide formatter should not be opinionated, especially in JS ecosystem.

If adding custom plugins was super easy to do, then this could be less of an issue if people can just easily build custom plugins (having good docs needed).

Make it super easy to build plugins for it

It's super hard to build plugins for Prettier. I was not successful building one.

Plugin system should be easy and feature reach. Top notch documents and examples. Tips qnd tricks. Performance guide.

Don't print every formatted file in the console

No one cares about this. It's not useful. If people want this, they can enable it using a CLI flag or config option.

Built-in package.json formatter

I've seen so many package.json files that there is no sorting done by the developer, and it's hard to find and work with the content inside it. It could be helpful if there was a good built-in enabled by default formatter for this. Just as example:

title
version
description
license
scripts

It should also be possible to fully customize the sorting order.

An issue/limitation of Prettier

prettier-plugin-tailwindcss: "Compatibility with other Prettier plugins"

More about the issue in another plugin. I wrote this:

IanVS/prettier-plugin-sort-imports#119 (comment)

And got this response:

IanVS/prettier-plugin-sort-imports#119 (comment)

It would be great if OXC formatter didn't have such issues/limitations.

Allow using comments to change formatting options for blocks of code

With Prettier it's not possible to change formatting options for a block of code using comments.

Something like this but for customizing config options:

// prettier-ignore-start

console.log()

// prettier-ignore-end

Also, Prettier plugins need to handle ignore comments by themselves instead of prettier itself handling it. As a result, not all plugins support this feature correctly. I'm not even sure if Prettier itself does it correctly.

Custom indentation for specific blocks of code

I'm working on a WordPress plugin and this is the result I get with Prettier:

<?php

$this->start_controls_section('tab:style/accordion:tab_content', [
]);

$this->add_responsive_control('tab_content_padding', [
]);

$this->end_controls_section();

Instead, I want this:

<?php

$this->start_controls_section('tab:style/accordion:tab_content', [
]);

    $this->add_responsive_control('tab_content_padding', [
    ]);

$this->end_controls_section();

Notice how add_responsive_control is indented, like there is an invisible scope/block. I need this because on the visual side of this code, add_responsive_control is a UI control inside an accordion. So, doing this allows me to scan trough code easily.

How could this be implemented? Using comments would be fine (like how I explained above). Having a way to configure the formatter so that it knows what to do without needing to add comments all the time, like easily creating q plugin, would even be better.

Don't blindly follow a rule

For example, don't break object key value pairs, in scenarios like this:

🔴 Bad:

{
    key:
        "very long string very long string very long string"
}

🟢 Good:

{
    key: "very long string very long string very long string"
}

Or this:

🔴 Bad:

const PUBLIC_SECRET =
    "very long string very long string very long string"

🟢 Good:

const PUBLIC_SECRET = "very long string very long string very long string"

Why? because:

• It makes code ugly and less readable.
• No developer in the universe likes this.
• It brings no readability value or any value at all.

Make this the default behavior and allow customization for crazy people.

Don't die on opinionated hill

Please don't stick with arguments like "A formatter should be opinionated". A great formatter should have great defaults and excellent and rich features, easy to use, customizable and easy to extend.

A cide formatter should not be opinionated, especially in JS ecosystem.

Break syntax in Markdown paragraph into multiple lines for readability

🔴 Before:

very long string very long string very long string ![image](/image.png) very long string very long string very long string.

🟢 After:

very long string very long string very long string
![image](/image.png)
very long string very long string very long string.

It kinda sucks at first, but it's good for readability. Deno fmt have this feature.

Prettier formats a TS code incorrectly

prettier/prettier#16492

Deno fmt does it correctly.

Better SVG formatting options

prettier/prettier#14424

Have an option where it can have the following formatting results:

1

<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" class="w-6 h-6"><path stroke-linecap="round" stroke-linejoin="round" d="M8.25 6.75L12 3m0 0l3.75 3.75M12 3v18" /></svg>

2

<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" class="w-6 h-6">
    <path stroke-linecap="round" stroke-linejoin="round" d="M8.25 6.75L12 3m0 0l3.75 3.75M12 3v18" />
</svg>

3

Whatever Prettier dies I guess.

Better CSS formatting

🔴 What Prettier does (bad):

@utility app-shell-tabs-content {
    padding-bottom: calc(
        var(--app-shell-footer-height) + var(--app-shell-floating-button-gap) +
            var(--app-shell-floating-button-size, 0px) +
            var(--app-shell-floating-button-gap)
    );
}

🟢 How it should be (good):

@utility app-shell-tabs-content {
    padding-bottom: calc(
        var(--app-shell-footer-height) +
        var(--app-shell-floating-button-gap) +
        var(--app-shell-floating-button-size, 0px) +
        var(--app-shell-floating-button-gap)
    );
}

Give an option to put the + at beginning or at end (Prettier have new option for this called experimentalOperatorPosition. Example:

@utility app-shell-tabs-content {
    padding-bottom: calc(
        var(--app-shell-footer-height)
        + var(--app-shell-floating-button-gap)
        + var(--app-shell-floating-button-size, 0px)
        + var(--app-shell-floating-button-gap)
    );
}

Why this useful, this immediately tells user that these are not items separated by space or comma, they are math values that + operator is used on them. Make it the default.

An issue with format on save and trailing commas

let's say I have the following code:

console.log(
    "... very long string ...",
    "... very long string ...",
)

I comment the second argument:

console.log(
    "... very long string ...",
    // "... very long string ...",
)

I save the file. Code gets formatted. This is the result:

console.log(
    "... very long string ..."
    // "... very long string ...",
)

Did you notice? the comma from the first argument got removed.

If I uncomment the second argument now, we will have a syntax error, or the code does something different than what it was supposed to do.

How to rix this issue? Just don't remove the comma in these sorts of scenarios.

prettier/prettier#17144

prettier/prettier#17285

prettier/prettier#17295

[heygarrett]

Indentation size set to 4

I would hope that, like Biome, the default would be indenting with tabs, for accessibility. That would allow everyone to use an indentation size that works best for them; you can use 4 columns, those accustomed to using 2 columns still can, those with impaired vision can make it as wide or as narrow as they need to, etc.