RFC: Formatter

[Boshen]

This discussion documents our decision process for our up coming formatter called oxfmt.

Prioritizations are performance and better DX.

Using structured comments below for better discussion.

[Boshen]

Architecture

• Optimize for the fast paths, where most files are in js / ts
• Rust CLI for parallelism
• Use prettier as a dependency for embedded languages
• When an embedded language is detected - call prettier to format the embedded language via napi. e.g. css in js
• Preconfigure prettier to call oxfmt if a language contains js or ts, e.g. js in markdown

[JakobJingleheimer]

I despise Prettier and stopped using Biome (in favour of oxlint) because of it. Several of Prettier's formatting rules make code less readable, and there is no way to disable or adjust them (aside from a bajillion tedious ignore comments littering a codebase), which makes the tool obnoxious.

[joaopedrodcf]

Is this plan of using prettier for other languages temporary ? Or is a plan for the long term ?

[Boshen]

Line Wrapping and printWidth

See https://antfu.me/posts/why-not-prettier

The most frequently criticized feature is Prettier's automatic wrapping and unwrapping of lines based on its printWidth setting (typically 80 or 100 characters). While intended to prevent horizontal scrolling, this behavior often creates significant "noise" in Git diffs. A minor change to a long string or function signature can cause an entire block of code to be reformatted, obscuring the actual logic change and making code reviews more difficult and time-consuming. In certain contexts, such as functional programming pipelines or long, chained method calls, the resulting formatting can be objectively harder to read than the original, manually formatted code. The inability to disable this behavior is a major and long-standing complaint.

[asamofal]

Oh yeah! Prettier makes me crazy with that.

This is a bit different case but connected to printWidth also:

// prettier-ignore
const currentRaw = typeof phoneNumber.value === 'string'
  ? phoneNumber.value
  : phoneNumber.value?.raw;

Without prittier-ignore it comes to:

const parsedPhoneNumber =
  typeof newPhoneNumber === 'string' ? parsePhoneNumber(newPhoneNumber) : newPhoneNumber;

Or another case:

// prettier-ignore
const {
  totalQty,
  totalPrice,
  customerDisplayName,
  employeeCustomer,
} = storeToRefs(useOrderStore());

const { totalQty, totalPrice, customerDisplayName, employeeCustomer } =
  storeToRefs(useOrderStore());

I simply refuse to believe that prettier developers accepted this as normal.

[WAKayser]

Being able to configure this behavior is nice. But having nicer defaults would be my preference. For example using commas to always place items on the next line. eg: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#trailing-commas.

[toniengelhardt]

Code is art! Let the artist decide how to break their lines. Prettier code has no soul.

[Boshen]

Builtin sorting and aesthetically features

• Remove the need for additional js plugins, which will slow down formatting as every file will need to call into prettier
• https://perfectionist.dev/
• https://github.com/lydell/eslint-plugin-simple-import-sort
• https://github.com/simonhaenisch/prettier-plugin-organize-imports
• https://github.com/tailwindlabs/prettier-plugin-tailwindcss

[DreierF]

Would you also consider adding https://github.com/hosseinmd/prettier-plugin-jsdoc?

[bjmiller]

Personally, I believe that organizing imports are a semantic concern, not a formatting concern. So, import sorting should really be built into oxlint. Yes, a formatter can do the sorting, and prettier is often used that way. But, that's not where it really belongs.

[PointSingularity]

There is also this one that fairly popular and has nice options as well (also already works with @prettier/plugin-oxc):

• GitHub linkhttp://github.com/ianvs/prettier-plugin-sort-imports - npm link

[Boshen]

Defaults

Defaults will be aligned to prettier for compatibility reasons.

[heygarrett]

It would be worth considering tabs as the default for indentation, which would be better for accessibility. For example, I struggle to visually parse code with two-space indentation. I need wider indentation. But a lot of folks have a preference for two-space indentation. With tabs as the default I can use four-space indentation and those who want to use two-space indentation still can. Everyone wins.
Prettier is considering this for 4.0 and Biome already defaults to tabs.

[GermanJablo]

The differences between Prettier and Biome are minimal, and I don't think they would affect any of the projects I'm working on.
But for reference, it might be good to take a look at this:
https://biomejs.dev/formatter/differences-with-prettier/

[Gugustinette]

It seems there's some kind of conflict between the need for backward compatiblity with Prettier and the hope for better defaults (specially as this new project opens new possibilities).

I would suggest to implement a preset option, which would be either :

• prettier, the default choice, with 100% backward compatibility
• oxfmt, the recommended defaults we consider generally better

[Boshen]

Why not dprint

Dprint has two parts:

• CLI + wasm plugins
• A js / ts formatter

We want to offer a better formatter.

We can offer a dprint wasm plugin for existing users of dprint.

[Hebilicious]

What do you mean specifically by a better formatter ? What would oxc formatter do, that dprint can't ?

Additional question, should the formatter be a standalone tool usable on its own, like Prettier or dprint or should it be more of an extension to oxc, like eslint.style ? Because in my opinion, an oxc formatter should not just try to be a faster prettier. It should try to be at least as good as eslint.style (for reference here are the supported rules).

Providing a painless migration path from existing tools is a great way to get adoption, so as someone using oxc + dprint or biome + dprint in all my projects (with vue formatting support through https://github.com/g-plane/markup_fmt), I'd be happy to migrate everything to oxc + plugins.
Obviously being able to use a single tool with a single configuration file to handle both formatting and linting would be better in the future.

[s3xysteak]

@Hebilicious 's words sound good to me. I am using @antfu/eslint-config which is powered by eslint-plugin-format. I believe a lot of vue/nuxt/unjs users are using that like me because of antfu of course. If oxc-formatter can be a plugin of oxlint, that will be so great. (Or a official plugin of oxlint, powered by oxc-formatter?)

[Boshen]

Built-in tailwindcss support?

https://github.com/tailwindlabs/prettier-plugin-tailwindcss

[JakobJingleheimer]

This is not the place to discuss your preference or dislike for Tailwind CSS. It is an integral part of the web development landscape nowadays

I expect (and hope) it will be a flash in the pan precisely because it's an anti-pattern (css utility classes are widely regarded as anti-pattern—this is not my own opinion I'm advocating). That is relevant because it means you will have mostly wasted the effort providing bespoke support for it.

If you don't use Tailwind, you won't have any negative consequences in terms of formatter perf or similar.

This is objectively not true:

1. It would distract oxfmt maintainers from doing more important work
2. It would bloat oxfmt
3. There would have some runtime cost (albeit likely trivial)

---

I do not appreciate nor think it was appropriate to hide my previous comment as off-topic. It was not, and nor was in inflammatory. My points were objective: they raised reasons to not support it.

Also, if you read my previous comment, you'll notice that I did not say to not support it at all, but rather proposed an alternative way of providing it that addresses the raised concerns.

[TheAlexLichter]

I expect (and hope) it will be a flash in the pan precisely because it's an anti-pattern (css utility classes are widely regarded as anti-pattern—this is not my own opinion I'm advocating).

That's more than fine! There is no need to argue here as the opinion on whether Tailwind is an anti-pattern or not is not relevant for the discussion.

That is relevant because it means you will have mostly wasted the effort providing bespoke support for it.

Tailwind CSS is heavily used in the web development world. It might be polarizing but doesn't change the fact that a lot of applications are using it. It would be foolish to ignore the demand for first-class formatting or disregard it (IMO).

1. It would distract oxfmt maintainers from doing more important work

This is more a question of priority. Tailwind CSS support will not be the most important feature to complete, so the "more important work" will come first.

2. It would bloat oxfmt

IMO a valid concern, but this should be checked when there is an implementation and making trade-offs then (considering the userbase, benefits etc.).

3. There would have some runtime cost (albeit likely trivial)

As you said, most likely negligible.

I do not appreciate nor think it was appropriate to hide my previous comment as off-topic. It was not, and nor was in inflammatory. My points were objective: they raised reasons to not support it.

Sorry if that action seemed harsh but to me your comment came across as: "I think Tailwind sucks, thus you shouldn't support it."

As discussed in #13608 (comment), the idea is to have as little JS plugins as possible to make sure performance is reasonable. Your idea of supporting Tailwind as (JS) plugin goes the same direction there.

[JakobJingleheimer]

As discussed in #13608 (comment), the idea is to have as little JS plugins as possible to make sure performance is reasonable. Your idea of supporting Tailwind as (JS) plugin goes the same direction there.

Ah, okay. I don't know how the mechanics work. I understand the desire to avoid criss-crossing the barrier which is expensive. I was imagining it would be whatever Rust's version of a plugin is, with a thin bit of glue.

If that's not really feasible, that's too bad, not least because of what others have mentioned: eslint's success is almost surely due in large part to its plugins.

I would say solving that would be a much better use of time before implementing a tailwind formatter.

[joaopedrodcf]

This will be a great feature 👌

[harrytran998]

Must have feature!

[Boshen]

Config support

• For the first release: single root .oxfmtrc.json. No .js, no extend, no override.
  • this is controversial, but for the first version we want to keep it simple.
  • future versions may relax these choices.
• Support .prettierignore
• Support .editorconfig

[marcuspoehls]

Is there a chance to get a .js config format? An oxfmt.config.js file would allow to typehint the export. And a type-hinted export would enable users to use IntelliSense for the available attributes. Or maybe an oxfmt.config.ts file with type-checking 🙂

[controversial]

Adding a $schema attribute to the JSON can provide similar typechecking & autocomplete behavior in intellisense

[jakst]

Can you do .jsonc? Comments are invaluable in config files.

[Gugustinette]

Loading JS/TS config files - with decent performances - is still a WIP (track antfu-collective/unconfig#43 which involves Rolldown).

IMO it's okay to keep it simple with json, specially while it's still in alpha and has a workaround with $schema.
It's already a lot of work to write a formatter 😆

[TrySound]

Proper html formatting would be a huge deal for many users. Currently prettier enforces jsx style for html.

<!-- prettier -->
<img src="" />

<!-- proper html -->
<img src="">

[firefoxic]

I would like to completely abandon eslint in favor of oxlint, but I can't do that without using third-party eslint plugins. This is because no formatter (at the moment) can provide the flexibility and accuracy that https://eslint.style offers. If oxfmt becomes its counterpart, then it has a future. Otherwise, it will just be another unnecessary (or even harmful) formatter like prettier and biome.

[Hideman42]

I do 100% agree with that, with eslint style you can be very much granular on your formatting rules.
For instances a few things that are useful:

• When to break line on function arguments, for instance with 4+ args you switch to multiline

  const funcA = (argA: string, argB: number, argC: MyType): MyResult => {
  }
  const funcB = (
    argA: string,
    argB: number,
    argC: MyType,
    argD: boolean,
  ): MyResult => {
  }

• JSX opening/closing bracket on same indent, max one child inline

  // Can:
  <h1><span>Hello World</span></h1>
  <h1>
    <span>Hello World</span>
    <i>icon<i/>
  </h1>
  // Cannot:
  <h1>
    <span>Hello World</span>
    <i>icon<i/></h1>
  <h1><span>Hello World</span><i>icon<i/></h1>

• JSX props sorting for instance: ref, id, className, style, on*, others

Just for listing a few, there is plenty other useful ones.

In the end formatting is not only how to print line but is really how to arrange the code in a standardized way that everyone can follow reducing the need to think/interpret.

[s3xysteak]

Can't agree anymore. It’s hard for people to abandon a long-standing, stable library just because of performance differences. By contrast, a library that shows clear advantages across multiple aspects can become the better choice—just like Vite once did compared to Webpack years ago.