Replies: 31 comments 113 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.
-
|
@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.
-
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
|
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.
-
At least, setting |
Beta Was this translation helpful? Give feedback.
-
|
Just adding to the choir of voices, foo
.bar()
.baz();and const x = foo
? bar
: baz;are indeed superior to the single-line versions. One of the reasons, actually, that made me give Oxc a shot was that Biome has no way to configure it either. No reason for me to make the switch yet, I guess. |
Beta Was this translation helpful? Give feedback.
-
foo
.bar()
.baz()
;and const x = foo
? bar
: baz
;allow for clear multiline statement ending, pretty much like the brackets do |
Beta Was this translation helpful? Give feedback.
-
|
I think the closest I've ever really come to having an alternative algorithm than prettiers could be would be that you declare a goal target print length, and then aim to bake some kind of '1 expression-like 1 line' system, where collections of nodes are treated as 'a unit' and they get flowed collectively (and there's a bit of a constraint resolution on how far it can go over to still keep the 1 expression on a single line It'd be a lifetime of edge cases I imagine |
Beta Was this translation helpful? Give feedback.
-
|
Would it be possible to have |
Beta Was this translation helpful? Give feedback.
-
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 |
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.
-
|
Honestly, using |
Beta Was this translation helpful? Give feedback.
-
If you mean the sort-import rule in |
Beta Was this translation helpful? Give feedback.
-
i mean all of |
Beta Was this translation helpful? Give feedback.
-
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 |
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.
-
Does it exist? It would offer us a smooth transition path to oxfmt. |
Beta Was this translation helpful? Give feedback.
-
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 |
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.
-
|
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.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
oxfmt configuration not supported extends ，Does the plan support this in the future? |
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.
-
|
An interesting blog post from @jakearchibald about this: |
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.
-
|
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.
-
|
Give me const x = foo
? bar
: baz;and I can die happy |
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.
-
|
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.
-
|
|
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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();
-} |
Beta Was this translation helpful? Give feedback.
-
|
sure disable by default... |
Beta Was this translation helpful? Give feedback.
-
|
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.) |
Beta Was this translation helpful? Give feedback.
-
|
What hostility did you see? |
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
-
|
IMO just having an option. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
That comes off a little unnecessarily hostile. I think Hugo was merely mistaken, not belligerent 😬 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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"; |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
has the |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
since oxlint doesn't support |
Beta Was this translation helpful? Give feedback.
-
|
Can you expand on the problem you're having with |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, didn't know about JS Plugins in Oxlint. I'll use it. |
Beta Was this translation helpful? Give feedback.
-
We are using tab width 4 for JS and TS, for other files - tab width of 2. |
Beta Was this translation helpful? Give feedback.
-
|
See #17585 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
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
|
Beta Was this translation helpful? Give feedback.
-
"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.
|
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
@firefoxic as I've heard from multiple ox authors that the initial phase of |
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