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.

[Hideman42]

So in the end the suggestion would be printWidthMin and printWidthMax.

I do agree too that sometimes it a bit annoying that it is wrapping for just a few char more. With min max the algo could say okey this line is over printWidthMax=130 then lets wrap it using printWidthMin=120 or a bit more up to 130.

And actually depending of the line the algo could reiterate, for instance wrapping a long function call could be done with several lines ranging char in between min/max the printing width without having to be strictly exact to 130 and probably a majority of lines be close or under printWidthMin=120

[Hideman42]

Additionally I think line wrapping should be also driven with other rules, if I take the example made by Boshen where you have an array of objects nice rules (that I believe we had similar things in eslint back days or now in eslint style) could be:

• If an object has 2 keys less try to keep one line
• If an object has 3 or more keys always wrap each attrs on new line
• An array should contains only unwrapped objects or only wrapped objects

Then alongside min/max printWidth this could make the wole thing more readable, but for sure be strict on printWidth isnt worth it I believe.

EDIT/PS:
We can expand this topic as well, I remember having some other rules looking similar on JSX.

• Inline JSX if you have only 1 children
• Wrap JSX if more than 1 child
• Closing JSX backet should be aligned vertically to the starting bracket, avoiding the following that can really happen with printWidth only

  <span>Hello
     {' '}
     <b>{userName}</b></span>
     
  <span>Hello <b>{userName}</b></span>
  
  <span>
    Hello
    {' '}
    <b>{userName}</b>
    <br/>
    What a nice day!
  </span>

[vjeux]

Curious what would be the proposed solution for this problem.

[zakius]

I like the idea of setting wrapping threshold and max sub-line length separately, the idea of keeping indentation and line breaks also would work, though neither would stop the behavior shown at the start of this thread I'm afraid

the idea to decide if object should be wrapped depending on number of properties may work, but there will likely be outliers anyway, like extra long properties

[zanminkian]

Curious what would be the proposed solution for this problem.

At least, setting printWith bigger can ease the problem. 80 is too sort, which makes unexpected line-break so frequent. But Prettier refused to change the default. 🤦‍♂️

[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

[tmm1]

I don't know where the line is, but it would be great to have auto-fix capable no-unused-imports

I'm also interested in import-newlines/enforce (github, npm)

[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

[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 😆

[cjnoname]

Does it support vscode settings?

"editor.tabSize": 2,
"editor.insertSpaces": true,
"editor.detectIndentation": false,
"editor.formatOnSave": true,
"prettier.trailingComma": "none",
"prettier.tabWidth": 2,
"prettier.semi": true,
"prettier.singleQuote": false,
"prettier.printWidth": 100,
"prettier.arrowParens": "avoid"

[Sysix]

Does it support vscode settings?

For the first version: No. When config files are supported, the server needs to evaluate which setting (VSCode vs config file) has the higher priority.
Another problem is a possible difference then between CLI and Editor.
That's why I want a single source of true for editor and CLI tool, see #13744 (comment)

[virtuallyunknown]

You mention that the first release will have limited configurability, but may I ask what are the long term goals here? In other words, is it going to be limited and opinionated by design like prettier, or will it expose more options to the user?

For the record, I understand what prettier's main selling points are and why many people use it, but personally I was never a fan of the idea that someone else should decide what my code looks like.

[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="">

[vjeux]

Sorry about it, we should probably not self close the elements that don't need to be. It's been many years. If you send a PR and tag me I'm happy to review it. Here's the list of elements that should have this pattern: https://stackoverflow.com/a/10599002

[ggascoigne]

To be pedantic, the prettier version is correct too, it might be redundant, but it's not wrong and is supported by the spec.

[orimay]

Also, closing such elements makes it explicit if they are self-sufficient

[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.

[gossi]

I mostly run eslint on save for formatting. Not because I want to run eslint, but due to its many styling packages and options it does what I am looking for (many from stylistic), far more than prettier can do (prettier runs as part of eslint though). It is also weird for me to run lint for formatting. I'm old enought to witness the need for lint (before compile) and I couldn't be more happy to have that separation back.

So if oxfmt and oxlint do get all the respective options (or plugins) + configs to run each tool for its own purpose, that is a switch I am happily waiting for.

[orimay]

Style/Script indentation

Would've been important to have vueIndentScriptAndStyle or something similar working, not only in Vue.

CSS, JS, HTML have indentation within them:

<html>
  <body>
  </body>
</html>

.text-blue {
  color: blue;
}

function a() {
  return;
}

But not having indentation on their edge is absolute nonsense:

<head>
  <style lang="text/css">
  .text-blue {
    color: blue;
  }
  </style>
</head>

should be

<head>
  <style lang="text/css">
    .text-blue {
      color: blue;
    }
  </style>
</head>

[yisibl]

Personally, I'm not a fan of indenting the first level within <style> tags. Especially now that native CSS supports nesting, this leads to excessive indentation.

<head>
  <style>
    .text-blue {
      color: blue;
      .bar {
        .baz {
          margin: 20px;
        }
      }
    }
  </style>
</head>

[orimay]

To me it looks better than <style> mixed with .text-blue {

<head>
  <style>
  .text-blue {
    color: blue;
    .bar {
      .baz {
        margin: 20px;
      }
    }
  }
  </style>
</head>

Four spaces could be a bit too much, but two spaces indentation makes code cleaner, organized, and doesn't really affect how much fits on the screen. Otherwise, we could abandon indentation inside each of HTML/JS/CSS for the sake of no excessive indentation :)

[husayt]

I was starting a new project and was about to go with prettier along with oxlint, when noticed [email protected] just been released. Used that and it works. Maybe not everything is supported, but i would rather have that with expectation that it will keep getting better, than having another project with prettier.

Things are coming together and that is making big difference on our end. Thanks team.

[ryanleichty]

I would love it if we could configure how ternaries are formatted https://x.com/pcattori/status/1734712411700023443

[pcattori]

I'm actually in the process of redoing my website right now, so if the link in that tweet doesn't work, try this one: https://github.com/pcattori/blog/blob/main/posts/ternaries-could-be-beautiful/index.md

[darrylyeo]

Would love to see an option that resembles the placement of curly braces in if / else if / else statements:

const result = (
  condition1 ?
    value1
  : condition2 ?
    value2
  :
    value3
)

[pcattori]

@darrylyeo my main gripe the if/else if/else style you proposed is that its cumbersome to comment out/move/delete the first condition since its corresponding : is on the same line as the next condition. Not only is editing more tedious, but it causes more git diff noise. For me, those are deal breakers. But if you just add a newline after the : then it works great.

[darrylyeo]

Traditional if/else if/else formatting arguably has the same problem, but I can see the advantage of newline after :.

const result = (
  condition1 ?
    value1
  :
  condition2 ?
    value2
  :
    value3
)

I usually only have two to three "cases" and tend to use object mapping constants for static value comparisons instead, so I don't often have the need to reorder conditional clauses the way you described.

[ryanleichty]

Oxfmt is not trying to be another opinionated formatter.

I could be wrong in my understanding of oxfmt's goals, but my assumption based on what they've said here and @antfu’s blog post, is that they intend to make it configurable. So my suggestion is merely that ternaries are configurable with various options available.

[ProCode-Software]

Can you please add an option to not indent switch cases? Like this:

switch (foo) {
case 1:
  // case 2
case 2:
    // case 2
}

Prettier adds indentation before each case, and there is no option to change it.

[darrylyeo]

Building off of preserving existing line breaks instead of enforcing a max print width – an option to enforce one level of indent for any expression already spanning more than one line (and parentheses if not otherwise fully contained within braces/brackets/backticks).

const sum = (
  variable1
  + superLongVariable2 * superLongVariable3 / superLongVariable4
  - variable5
)

const result = (
  condition1 ?
    value1
  : condition2 ?
    value2
  :
    value3
)

const nodes = [
  tree
    .getRootNode()
]

console.log(
  'The value will be',
  (
    variable1 && variable2 && (
      variable3?.method?.()
      ?? variable4
    )
  ),
  `at time ${
    Date.now()
    + 24 * 60 * 60 * 1000
    + 10 * 60 * 1000
  }`
)

const visibleItems = (
  [
    {
      x: 1,
      y: 2,
    },
    {
      x: -3,
      y: -4,
    },
    {
      x: (
        left + (
          element
            ?.getBoundingClientRect()
            .width
          ?? 0
        )
      ),
      y: 10,
    ),
  ]
    .filter(({ x, y }) => (
      x > 0
      && y > 0
    ))
)

TypeScript types too:

type Color = (
  | 'RED'
  | 'GREEN'
  | 'BLUE'
)

type Options = (
  | false
  | {
    foo: string
    bar: number
  }
  | (
    & {
      hello: string
      world: number
    }
    & MoreProps
    & EvenMoreProps
  )
)

[Hugos68]

What's the status on Vue/Svelte support? I couldn't find any info on this, will this be part of 1.0?

[gossi]

... and Ember? Do you plan to use the same js-plugin idea for oxlint and plan extension through that? Or do you collaborate with framework dev teams to incorporate their rules into core?

[ghiscoding]

Currently running oxfmt . will reformat any files that are not conforming to the rules. Should we expect the same CLI option as what Prettier --check already offer? This is helpful when running in CI/CD environments.

[Hugos68]

[ghiscoding]

hey thanks a lot, I'm not sure why it failed in the npm script the last time I tried but nice to see it in the CLI help. I'll retry tonight, thanks 👍🏻