Replies: 20 comments 73 replies
-
Architecture
|
Beta Was this translation helpful? Give feedback.
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
So in the end the suggestion would be 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 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 |
Beta Was this translation helpful? Give feedback.
-
|
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:
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:
|
Beta Was this translation helpful? Give feedback.
-
|
Curious what would be the proposed solution for this problem. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
At least, setting |
Beta Was this translation helpful? Give feedback.
-
Builtin sorting and aesthetically features
|
Beta Was this translation helpful? Give feedback.
-
|
Would you also consider adding https://github.com/hosseinmd/prettier-plugin-jsdoc? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
There is also this one that fairly popular and has nice options as well (also already works with |
Beta Was this translation helpful? Give feedback.
-
|
I don't know where the line is, but it would be great to have auto-fix capable I'm also interested in |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
DefaultsDefaults will be aligned to prettier for compatibility reasons. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
The differences between Prettier and Biome are minimal, and I don't think they would affect any of the projects I'm working on. |
Beta Was this translation helpful? Give feedback.
-
|
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
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@Hebilicious 's words sound good to me. I am using |
Beta Was this translation helpful? Give feedback.
-
Built-in tailwindcss support? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
This will be a great feature 👌 |
Beta Was this translation helpful? Give feedback.
-
|
Must have feature! |
Beta Was this translation helpful? Give feedback.
-
|
If we're talking about extensions, it might be a good idea to consider having import sorting. |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/IanVS/prettier-plugin-sort-imports why not this one instead @KacperKozak? |
Beta Was this translation helpful? Give feedback.
-
Config support
|
Beta Was this translation helpful? Give feedback.
-
|
Can you do .jsonc? Comments are invaluable in config files. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Does it support vscode settings? "editor.tabSize": 2, |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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=""> |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
To be pedantic, the prettier version is correct too, it might be redundant, but it's not wrong and is supported by the spec. |
Beta Was this translation helpful? Give feedback.
-
|
Also, closing such elements makes it explicit if they are self-sufficient |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
What do you mean by “harmful”? |
Beta Was this translation helpful? Give feedback.
-
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> |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I'm not a fan of indenting the first level within <head>
<style>
.text-blue {
color: blue;
.bar {
.baz {
margin: 20px;
}
}
}
</style>
</head> |
Beta Was this translation helpful? Give feedback.
-
|
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 :) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I would love it if we could configure how ternaries are formatted https://x.com/pcattori/status/1734712411700023443 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Would love to see an option that resembles the placement of curly braces in |
Beta Was this translation helpful? Give feedback.
-
|
@darrylyeo my main gripe the |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
I could be wrong in my understanding of |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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
)
) |
Beta Was this translation helpful? Give feedback.
-
|
What's the status on Vue/Svelte support? I couldn't find any info on this, will this be part of 1.0? |
Beta Was this translation helpful? Give feedback.
-
|
... and Ember? Do you plan to use the same js-plugin idea for |
Beta Was this translation helpful? Give feedback.
-
|
I just found this issue which is probably what you were looking for... #15899 |
Beta Was this translation helpful? Give feedback.
-
|
Currently running |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
|
Hey, anyone figured out how to integrate oxfmt with lint-staged? My config: "lint-staged": {
"*": "oxfmt",
"*.{ts,js,mts,mjs,cjs,json}": "oxlint --fix"
}My result: |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps add |
Beta Was this translation helpful? Give feedback.
-
|
I added a pre-commit hook section to the docs page :) https://oxc.rs/docs/guide/usage/formatter.html#pre-commit-hook TL;DR do this: |
Beta Was this translation helpful? Give feedback.
-
|
Will there be a equivalent of and/or compatibility with Documented comments:
|
Beta Was this translation helpful? Give feedback.
-
|
It looks to support |
Beta Was this translation helpful? Give feedback.
-
Let's say I'm using prettier with
I'm a bit conflicted because on one hand it should fallback to prettier for non supported formats, but on the other it won't let prettier fallback with plugins? |
Beta Was this translation helpful? Give feedback.
-
Is there a list of planned embed parent-child pairs? Or should community members create new posts in this discussion to ask for support? For example, I'm really enjoying SQL-in-JS via
Source: |
Beta Was this translation helpful? Give feedback.
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.
Beta Was this translation helpful? Give feedback.
All reactions