Replies: 35 comments 125 replies
Architecture
|
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@karchung0930 @Hugos68 Appreciate the conversation but this is a bit out of scope for a comment on an RFC. Please feel free to jump on e.g. our Discord. I've hidden your comments for better overview of the long discussion here. I still would like to touch on a few points mentioned throughout it. PerformanceThere is a real need for better formatting performance compared to prettier and Oxfmt is offering that. For direct numbers/comparison, please have a look at our benchmark repo. Prettier-compatibility
As it was already pointed out, migrating away from an existing formatter, which is most likely prettier, does pose a risk. Which can be mitigated if Oxfmt is as prettier-compatible as possible (not "just 90%" or similar). We've also listed differences in a separate discussions and even found bugs in prettier while working on Oxfmt. But being compatible by default doesn't mean that it is "only prettier-compatible".
That's why the goal Oxfmt isn't "pure prettier compatibility" but goes beyond that, also with loosening some conventions (e.g. the different |
|
Edit: Oops, this tab was a bit outdated, didn't see the prior comments were marked as off-topic. 😅 Hidden comment
This is not true at my company. We're not using Prettier because it's too opinionated (currently using ESLint Stylistic), and would probably use it even if it is pretty slow. Though we are also seeking a faster tool since So at least for us, we're excited that direction of the Oxc Formatter is intended to be both fast and more flexible than Prettier, although with good defaults. |
Question: Should Embedded Formatters Receive Print Width Information?The ProblemEmbedded formatters (for CSS, GraphQL, HTML in template literals) only receive Example: const styles = css`
.container { background: blue; } // formatted for 100 char width
`; // but gets indented by outer code, causing overflowThe Core IssueEmbedded formatters are called during IR construction phase, before indentation is calculated. Indentation only becomes available during the Printer phase. This is an architectural limitation of how oxc currently works. Questions for the Team
|
Line Wrapping and printWidthSee 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. |
|
Would it be possible to have |
|
dprint just has |
|
As an example of how formatter can work without Basically, as far as I understand, it doesn't wrap code at all. If the developer writes 2 lines to define a struct or function parameters, it will be 2 lines. If dev writes 3 lines, then it will be three IMO it's how formatters should work in JS as well. If the developer says that this code will be written like that, the formatter will respect that and only add some spaces and tabulation without merging code into one line or splitting it into many Example in Go after formatting: package ui
type User struct {
name string
surname string
age int
}
func newUser() []*User {
return []*User{
&User{name: "User1", surname: "User1 surname", age: 1},
&User{
name: "User2",
surname: "User2 surname",
age: 2,
},
&User{
name: "User3", surname: "User3 surname", age: 3,
},
&User{name: "User4",
surname: "User4 surname", age: 4},
&User{name: "User5", surname: "User5 surname",
age: 5},
}
} |
|
I'm new to oxc. I use it bundled with VitePlus. Coming from eslint, never used prettier and I really dig what oxc is trying to achieve. The clear line between linting and formatting is a welcomed concept. But there is one particular option that makes me disable the entire fmt just because there is no way around it. I'm talking obviously about If you think I sound triggered, you're absolutely right. Amongst several shenanigans throughout my codebase with this rule, I tilted when one of my sentence's last (ノಠ益ಠ)ノ彡┻━┻ |
|
It's been about 10 months since this discussion started with 55 upvotes at this time, which seems high among oxc discussions. I am wondering if this is going to lead to anything? We have not heard from the maintainers regarding this since the original post. |
Builtin sorting and aesthetically featuresRemove the need for additional js plugins, which will slow down formatting as every file will need to call into prettier Sort imports (Partially supported)Based on https://perfectionist.dev/rules/sort-imports Tailwind CSS (Supported)Based on https://github.com/tailwindlabs/prettier-plugin-tailwindcss |
|
Not sure if feedback is useful but I 100% agree that sorting important is a semantic change, and thus does not belong in a formatter. Prettier made the right choice in never implementing this. |
|
Honestly, using |
If you mean the sort-import rule in |
i mean all of |
Consider using oxlint's JS plugins https://oxc.rs/docs/guide/usage/linter/js-plugins.html, although that specific library hasn't been tested, it should just work |
DefaultsDefaults will be aligned to prettier for compatibility reasons. |
|
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. |
|
The differences between Prettier and Biome are minimal, and I don't think they would affect any of the projects I'm working on. |
|
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
|
Why not dprintDprint has two parts:
We want to offer a better formatter. We can offer a dprint wasm plugin for existing users of dprint. |
|
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. |
|
@Hebilicious 's words sound good to me. I am using |
Does it exist? It would offer us a smooth transition path to oxfmt. |
Built-in tailwindcss support?https://github.com/tailwindlabs/prettier-plugin-tailwindcss Edit: Tailwind CSS has been supported, based on https://github.com/tailwindlabs/prettier-plugin-tailwindcss. See the configuration at https://oxc.rs/docs/guide/usage/formatter/config-file-reference.html#experimentaltailwindcss Related: issues/PRs |
|
Must have feature! |
|
If we're talking about extensions, it might be a good idea to consider having import sorting. |
|
https://github.com/IanVS/prettier-plugin-sort-imports why not this one instead @KacperKozak? |
|
If Tailwind support is built-in just because many people use it, you might as well support jQuery. I'd vote against bloating oxfmt's core with library-specific code. Keep it clean, keep it separate. |
|
@Anoesj too late mate, it's already in and working 🔥 |
Config support
|
|
Does it support vscode settings? "editor.tabSize": 2, |
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. |
|
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. |
I think this is necessary, just like the prettier extension, which integrates binary and supports vscode settings configurations, and workspace configurations have a higher priority than settings configurations. |
|
oxfmt configuration not supported extends ，Does the plan support this in the future? |
|
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=""> |
|
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 |
|
To be pedantic, the prettier version is correct too, it might be redundant, but it's not wrong and is supported by the spec. |
|
Also, closing such elements makes it explicit if they are self-sufficient |
|
An interesting blog post from @jakearchibald about this: |
|
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. |
|
I do 100% agree with that, with eslint style you can be very much granular on your formatting rules.
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. |
|
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. |
|
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 |
What do you mean by “harmful”? |
|
Same here, I'm really hoping to replace |
Style/Script indentationWould've been important to have 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> |
|
Personally, I'm not a fan of indenting the first level within <head>
<style>
.text-blue {
color: blue;
.bar {
.baz {
margin: 20px;
}
}
}
</style>
</head> |
|
To me it looks better than <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 :) |
|
I was starting a new project and was about to go with prettier along with Things are coming together and that is making big difference on our end. Thanks team. |
|
I would love it if we could configure how ternaries are formatted https://x.com/pcattori/status/1734712411700023443 |
|
Would love to see an option that resembles the placement of curly braces in |
|
@darrylyeo my main gripe the |
|
Traditional 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. |
I could be wrong in my understanding of |
|
Give me const x = foo
? bar
: baz;and I can die happy |
|
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. |
|
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
)
) |
|
What's the status on Vue/Svelte support? I couldn't find any info on this, will this be part of 1.0? |
|
... and Ember? Do you plan to use the same js-plugin idea for |
|
I just found this issue which is probably what you were looking for... #15899 |
|
Just recently discovered this project and really excited to see where it goes, all I ask is please give us, the developers, the ability to configure the formatter the way we want and don't go down the philosophy route of prettier and Biome as well. You're using rust, take a look at rustfmt's configurability, you have complete control over things, the way it should be. Fortunately the defaults are good and I've never felt myself needing to deviate from them but they're there if you want to change them. Please do the same, provide good sane defaults but ultimately let developers/teams/orgs decide for themselves. I've lost more years off my life having mental breakdowns over prettier's formatting decisions then I would ever have lost to "bikeshedding" (which in my 6 years of using of eslint has hardly ever been a problem, almost feels like a made up problem at this point). I'm currently at the point where I'm solely relying on eslint as a formatter for typescript and svelte on small projects, not ideal for svelte template formatting but it lets me configure what's best for me or my team and easiest to parse/read and understand, not some developers personal opinion on the "best way" other developers read code. |
|
would like to have an option to support: https://eslint.style/rules/brace-style#stroustrup , this is the only reason I use eslint.style. just feel this style is more easy to read(using diff colour to compare difference): +if (foo) {
+ bar();
+ }
- else {
- baz();
-}
+if (foo) {
+ bar();
} else {
- baz();
-} |
|
sure disable by default... |
|
I will never understand the automatic hostility towards adding an option that isn't the default, for a code style that can be argued to be functionally superior (standard/standard#219). The lack of stroustrup style support is why I cannot use biome as a formatter and I use a forked version of prettier instead of raw prettier. (Not here to debate 1tbs vs stroustrup vs allman, just pointing out that downvoting an option that nobody is forcing you to use, that has provable benefits for some, that would allow codebases that don't use 1tbs to adopt oxfmt, is beyond stupid. This hostility can be seen in biome/eslint/prettier discussions regarding brace style as well.) |
|
What hostility did you see? |
|
The hostility in this thread: actively making the effort to downvote a suggestion to provide this option instead of just not upvoting and moving on with a feature that does not affect them in any way. The presence of downvotes serves to actively discourage a feature from being implemented. With other formatters, maintainers are immediately dismissive of a need for such an option and hide behind the excuse of zero-config, when this is something important enough to be disqualifying for a formatter to be adopted by a repo using any non-1tbs style. Or, justifying only supporting 1tbs solely because it is prevalent and not because of any functional reasoning and ignoring the functional reasoning provided for other styles. Examples: |
|
IMO just having an option. |
|
The architecture decision to use Prettier as a fallback for embedded languages is pragmatic - trying to reimplement CSS-in-JS formatting from scratch would be a huge undertaking with diminishing returns. Regarding the printWidth/line wrapping criticism: I think the key insight from antfu's post is that predictable formatting > theoretically optimal formatting. When a formatter produces different output depending on line length thresholds, it creates noisy diffs. Maybe oxfmt could offer a mode that's more conservative about reflowing - only break lines that exceed the limit, but don't eagerly collapse short lines. For builtin sorting: huge +1. Having to pull in JS plugins for import sorting defeats the purpose of a fast Rust formatter. The perfectionist.dev rules are a good reference for what people want. |
|
I would like an option (preferably the default since Prettier's behaviour is breaking) to ignore comments. Just don't touch them at all. Prettier forces the comment onto a new line in the following, causing a broken CI {
- projects: [ // …disable x-rule
+ projects: [
+ // …disable x-rule
]
}In addition to not breaking CI, there are also benefits to putting the comment on the same line, such as code folding (when same line, the comment is displayed; when next line, the comment is hidden), so when the comment is explanatory instead of an override, you still get the explanation but don't have to have a huge chunk of code showing. |
Well prettier's behavior may or not be correct, that's rather subjective, but What you are describing suggests that all whitespace is equal in javascript, and that's just now it works, newlines are treated significantly differently. |
|
That comes off a little unnecessarily hostile. I think Hugo was merely mistaken, not belligerent 😬 |
apologies, that certainly wasn't the intent. That said, the whole issue with formatting is that it's opinion based, and "best practice" is often just a popular set of opinions. Being clear about what's fact and what's opinion does seem relevant. |
|
No offense taken, I didn't feel like there waa any hostility, what I meant is that I don't understand the example you shower above:
This is invalid JS as the closing bracket would be commented out, which is why I was mentioning "inline" comments like /* code */ as you, the author get to decide where it ends. |
|
Ah, okay. I read too much into it then 😅 I otherwise agree
True, but that's not the scenario I cited (and it's not relevant). |
|
is it possible to sort e.g. with import { getTranslations } from "next-intl/server";
import { notFound } from "next/navigation";but with import { notFound } from "next/navigation";
import { getTranslations } from "next-intl/server"; |
|
There is also seem to be a case where one would prefer to use linter instead of formatter (e.g. eslint stylistic over prettier to have full control, which seem to work as a js plugin just fine with oxlint). However import sorting available only in oxfmt formatter without the ability to turn off other formatter changes (max width or indent) still makes you to rather use |
|
has the |
|
It's pretty common to put those at the end. See original implementation https://github.com/keithamus/sort-package-json/blob/e3f2370982fdd22fbf6d68ab8c9690f3a767f834/index.js#L551-L554 and also see our groupings https://github.com/keithamus/sort-package-json/blob/e3f2370982fdd22fbf6d68ab8c9690f3a767f834/index.js#L551-L554 |
|
since oxlint doesn't support |
|
Can you expand on the problem you're having with |
|
Thank you, didn't know about JS Plugins in Oxlint. I'll use it. |
We are using tab width 4 for JS and TS, for other files - tab width of 2. |
|
See #17585 |
|
Thank you! |
Attributes on new line, only for long linesPrettier has the option A short tag that fits on one line would then format like this ( <v-row dense v-if="task.meta.chosenCategory">While a large tag would wrap every attribute: <v-autocomplete
:data-testid="'task_value_' + task.id"
ref="task-name-refs"
v-model="task.task"
return-object
:items="filterTasksByCategory(task.meta.chosenCategory)"
:rules="rules.task"
:menu-props="{ closeOnContentClick: true }"
:item-title="'name_' + t('lang')">This way
|
"preserve" for CSS/SCSS similar to objectWrapThis formatting change is undesirable: - padding:
- calc(var(--px-base) * 3)
- calc(var(--px-base) * 3)
- calc(var(--px-base) * 2)
- calc(var(--px-base) * 3);
+ padding: calc(var(--px-base) * 3) calc(var(--px-base) * 3)
+ calc(var(--px-base) * 2) calc(var(--px-base) * 3);
}"preserve" for function arguments similar to objectWrapThis formatting change is undesirable: - public async loadActor(
- ids: number[],
- actor: ActorName = 'Humanoid'
- ) {
+ public async loadActor(ids: number[], actor: ActorName = 'Humanoid') {In both cases, we can know to intention to preserve the formatting under the condition that there is a newline prior to the first property.
|
Yes, it's undesirable, but also inevitable. It's easier to accept it and not use oxfmt. That's what I did when I found out that instead of making the first non-breaking formatter, they made another one just like prettier and biome, i.e., a formatter based on line length restrictions. Every single formatter that is based on line length restrictions and doesn't allow you to turn off this nonsense completely (and that's all of them) is dead to me. That's why I continue to use |
|
@firefoxic as I've heard from multiple ox authors that the initial phase of |
|
Is the long-term plan to keep prettier for some file formats under the hood, or will oxfmt slowly replace it with a native implementation? |
|
The formatter design space is interesting because the goals of a formatter and a linter are in tension in ways that aren't obvious upfront. A linter needs to be configurable (teams have different opinions about what's an error vs a warning). A formatter needs to be opinionated (the whole point is to end style debates by making configuration impossible or trivial). Combining both in one tool means managing these conflicting design philosophies. The Prettier trade-off: Prettier wins by limiting options aggressively. The few options it has (line width, quote style, semicolons) are there because they affect code behavior or are literally impossible to enforce without them. Everything else is "not your decision." This is why Prettier adoption works — nobody can bikeshed because there's nothing to argue about. The risk with more options: if oxfmt adds options to satisfy everyone's preferences, you end up with the gofmt/black level of adoption where everyone uses the default config and a few holdouts don't. But you lose the "zero config" story that makes formatters so valuable. What I'd suggest considering:
The performance argument for a Rust-native formatter is compelling even before any UX features — the wall clock time difference on large codebases is real. That alone will attract adoption. For AI-generated code workflows specifically, a fast zero-config formatter is especially valuable — formatters run in every code generation pipeline and speed matters at that scale. |
|
Sorry to be blunt, but… Just keep using Prettier and making your code look ugly. And don’t get in the way of normal people formatting their code in a way that’s clear, readable, and usable. |
|
I disagree with this statement:
The goal of being opinionated does not necessarily exclude being configurable. Prettier's goal was to be as non-configurable as possible to end style debates, but other projects does not need to adapt that same philosophy. Less configuration is also partly motivated by reduced maintenance burden, as it's easier to maintain Prettier with less options. At the detriment of users who want more readable code. It would be one thing if JavaScript like many newer programming languages had a de-facto formatter (e.g. Other formatters have so far leaned into Prettier's approach (e.g. |
|
Can we have just one configurable formatter, please? Just one, where I can set it up so ternaries and method chains are split across multiple lines? Pretty please? |
|
I asked about this last year, and I got this reply. I hope that the goals haven't changed because Prettier just isn't good enough for a lot of people, sometimes it produces unreadable mess of a code. That aside, I think a good middle ground is to just ship oxfmt with defaults aligned with Prettier's, which I believe is what is happening right now. This way you keep the zero-config people happy, you install and call it a day. And for the rest of us, you allow to tweak things around. Just my 2 cents. |
|
Please add an option to avoid wrapping JSX returns. This is the reason I stopped using Prettier. There is significant demand for this option. Instead of const Comp1 = () => {
// ...
return (
<div>
...
</div>
)
}
const Comp2 = () => (
<div>
...
</div>
)
const Comp3 = () => (
<Comp4
attr1={...}
attr2={...}
attr3={...}
/>
)Format to this const Comp1 = () => {
// ...
return <div>
...
</div>
}
const Comp2 = () => <div>
...
</div>
const Comp3 = () =>
<Comp4
attr1={...}
attr2={...}
attr3={...}
/>The parentheses add more punctuation and make it harder for me to read. Apologies if there is already a discussion about this or a feature that already accomplishes this; I couldn't find anything |
[CSS] single line property formattingReferencing this prettier discussion which talks about a limitation I always struggled with when using prettier. // input - just a short example, it becomes much worse with real-world examples
@keyframes rainbow {
0% { color: #ff0000 };
50% { color: #9bff00 };
100% { color: #ff00ff };
}
// output (considered bad)
@keyframes rainbow {
0% {
color: #ff0000;
}
50% {
color: #9bff00;
}
100% {
color: #ff00ff;
}
}Arguments for this feature:
|
and others
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions