Original file

https://github.com/vuejs/core/blob/45547e69b25baa99a0ed52ba5110c5bd8b4a35e4/packages/compiler-core/src/ast.ts#L483-L504

Options:

Default

Input:

With a leading line comment before the TSUnionType

export interface DirectiveArgumentNode extends ArrayExpression {
  elements: // dir, exp, arg, modifiers
  | [string]
    | [string, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode, ObjectExpression]
}

Oxfmt output:

export interface DirectiveArgumentNode extends ArrayExpression {
  elements: // dir, exp, arg, modifiers
    | [string]
    | [string, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode, ObjectExpression]
}

Prettier output:

export interface DirectiveArgumentNode extends ArrayExpression {
  elements: // dir, exp, arg, modifiers
  | [string]
    | [string, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode, ObjectExpression];
}

Prettier output without // dir, exp, arg, modifiers comment:

export interface DirectiveArgumentNode extends ArrayExpression {
  elements: 
    | [string]
    | [string, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode]
    | [string, ExpressionNode, ExpressionNode, ObjectExpression];
}

The Oxfmt is exactly the same as Biome for this case, and we think the current Oxfmt output is better than Prettier's from a readability and consistency perspective.

Original file

https://github.com/vuejs/core/blob/45547e69b25baa99a0ed52ba5110c5bd8b4a35e4/packages/runtime-core/src/componentEmits.ts#L193-L202

Options:

Default

Input:

props[handlerName = toHandlerKey(event)]

Oxfmt output:

props[handlerName = toHandlerKey(event)]

Prettier output:

props[(handlerName = toHandlerKey(event))]

The assignment inside the brackets of ComputedMemberExpression does not need to be wrapped in parentheses. There are no semantic changes regarding whether to wrap a parenthesis or not, and I have not found a reason why Prettier did it.

Input

export default {
  head: [
    [
      'meta', { name: 'robots', content: 'index, follow' },
    ],
    [
      'meta', { name: 'viewport', content: 'width=device-width, initial-scale=1.0' },
    ],
  ],
};

oxfmt output:

export default {
  head: [
    ['meta', { name: 'robots', content: 'index, follow' }],
    ['meta', { name: 'viewport', content: 'width=device-width, initial-scale=1.0' }],
  ],
};

Prettier output:

export default {
  head: [
    ['meta', { name: 'robots', content: 'index, follow' }],
    [
      'meta',
      { name: 'viewport', content: 'width=device-width, initial-scale=1.0' },
    ],
  ],
};

"lineWidth": 120, I think oxfmt is better.

Options:

Default

Input:

const defaultColorDecoratorsEnablement = accessor
  .get(IConfigurationService)
  .getValue<"auto" | "always" | "never">(
    "longlonglonglonglonglonglonglonglong",
  );

Oxfmt and Biome's output:

const defaultColorDecoratorsEnablement = accessor
  .get(IConfigurationService)
  .getValue<"auto" | "always" | "never">(
    "longlonglonglonglonglonglonglonglong",
  );

Prettier output:

const defaultColorDecoratorsEnablement = accessor
  .get(IConfigurationService)
  .getValue<
    "auto" | "always" | "never"
  >("longlonglonglonglonglonglonglonglong");

I found this case in the VSCode repo. From my first look, I think Oxfmt's output is prettier than Prettier's, but considering compatibility, I already fixed the issue in #14983. However, I suspect this is actually a bug in Prettier and wrote my thoughts in its description, so track the problem here. Learn more at #14983.

Couple of examples I'm seeing after trying oxfmt on large codebase.

1. The comment at the end of the return () statement is moved outside of )

2. Different wrap at 120 chars

3. ): and comment

4. HTML rearranged

Reporting some minor prettier-ofmt differences I discovered. Overall the compatibly seems impressive (ran it over 40k+ files, had less than 50 differently formatted) :)

Using prettier 3.7.4 and oxfmt 0.23.0.
No configuration needed.

Prettier formatted reproduction:

type SomeType<T> = any;
type OtherType = any;

const x = [].reduce(() => {
  return "y";
}, {} as SomeType<OtherType>);

Oxfmt formatted reproduction:

type SomeType<T> = any;
type OtherType = any;

const x = [].reduce(
  () => {
    return "y";
  },
  {} as SomeType<OtherType>,
);

I can only speculate it has something to do with the generic bracket notation <OtherType>. Without using a generic there are no formatting differences

The // prettier-ignore flag works at the end of lines, which is great for really long debug/logging statements, where you don't want to distract the reading experience of a developer by turning it into a block spanning multiple lines. It's not a documented feature of prettier and it isn't supported in oxfmt at the moment for performance reasons.

With prettier:

logger({ level: 'info', message: `bla bla really long wow ${someVariable} more stuff wow owow woohooo ok more stuff ${x}` });  // prettier-ignore
logger({ level: 'debug', message: `User ${user} called .... });  // prettier-ignore

With oxfmt:

// prettier-ignore
logger({ level: 'info', message: `bla bla really long wow ${someVariable} more stuff wow owow woohooo ok more stuff ${x}` });
// prettier-ignore
logger({ level: 'debug', message: `User ${user} called .... });

I would start from the belief that code is more often read than written and that whoever writes code does so wanting to guide the human readers of code through the intention of the code. So here we're turning a one-liner that says "this is a debug/toast/logging statement, you probably don't need to care about this, keep reading" into a two-liner purely because of a formatting tool. Being two lines it now draws more attention than before, and if you have multiple instances right next to each other, then what was two or three lines before is now four or six.

Of course performance is crucial and I understand that implementing this would involve some kind of backtracking or scanning ahead, but my feeling is that this particular undocumented prettier feature is actually more impactful that it might seem at first glance.

Personally, I would be very excited if we could find a way to bring it to oxfmt in a performant way, or add a different syntax/feature to enable these long debug/logging one-liners in oxfmt.

See #16915 and #18654