As JSDoc is always contained within the ` * ` fenced comments, the `printWidth` option should not have been used as is.
The dedicated `jsdocPrintWidth` option has not yet been implemented. #24633
Follow-up to #25063.
tsx-in-vue was supported in #25063 with a parse-retry (ts fails → retry as tsx), chosen to keep the common ts path single-parse.
However, this leaves a hole: a `lang="tsx"` block without JSX parses fine as plain ts, so the retry never fires and the lone generic comma is removed:
```vue
<script setup lang="tsx">
const identity = <T,>(x: T) => x; // → <T>(x: T) => x, breaks as TS17008
</script>
```
Since parse failure fundamentally cannot detect this, the only fix is to scan the `lang` declaration itself.
The JS host now scans the SFC once per file and passes `_oxfmtVueScriptLang: "tsx"` down to `textToDoc()`. This makes the retry obsolete, so it is removed.
This PR also settles the comma policy: keep it only where it is load-bearing.
- JSX grammar (`<T>` would be a JSX opener)
- and `.mts/.cts` (TS7060, #18928)
and remove it everywhere else, keyed on the grammar, regardless of context.
Deliberate divergence: Prettier keys on filepath and keeps the comma in ts-in-vue/svelte (while its own ts-in-md embed uses `dummy.ts` as `filepath` and removes it). Plain-TS sources now behave identically wherever they live.
Part of #16608, closes#25046.
---
Even with a simple regexp, I don't want to impact the performance of the vast majority of ts-in-vue paths.
With this approach, only tsx-in-vue use cases will be affected, and even that will be kept to a minimum since it can be handled entirely on the Rust side. (JS <-> Rust roundtrip is also slow)
Introduce `exact_line_breaks(count)` IR builder.
This produces a line element that prints exactly `count` line breaks, exempt from the printer's hardline collapsing / empty-line capping.
Blank runs inside verbatim values (YAML block/flow scalars, GraphQL block strings) are the value itself and must not be normalized.
Previously this was emulated by emitting raw `\n` text followed by a re-arming `hard_line_break()`..., hack.
Also removed the printer behavior that trims end of line whitespaces.
Fixes#24000, #24057, and #24116.
Updating `oxc-css-parser` to 0.0.4 involved a massive amount of fixes, making it a major update.
However, this should allow us to catch cases that were previously missed (even potentially).
- Fork `apollo-rs` to be compatible with Prettier(`latest` for now)
- https://github.com/leaysgur/apollo-rs
- By doing this, Prettier fallback is no longer needed
- And now all prettier_conformance are passed, no parse error skip
> [!WARNING]
> TODO: Move fork under `oxc-project` org and replace refs
- Before this PR: If `sortTailwindcss` option is enabled for CSS/LESS/SCSS, it was formatted by Prettier
- After this PR: `oxc_formatter_css` also handles `sortTailwindcss` as like `oxc_formatter` does
In addition to basic embedded (e.g. css-in-js), JSDoc also contain code fence as markdown.
This PR makes JSDoc code fence also formatted by `oxc_formatter_(css|graphql)` if specified.
- Use `oxc_formatter_css` from Oxfmt to handle CSS/LESS/SCSS files
- css-in-js is also handled by `oxc_formatter_css`
- But it will fallback to Prettier if formatting failed
- No fallback for no-embedded path
- At the point of this PR, it will fallback to Prettier when tailwind is required to format
NOTE: Both fallback will be removed in later PR.
In that sense, as a result of this series of PRs, Oxfmt's CSS support will no longer be 100% compatible compared to Prettier.
Since the parsers used are also different, it will no longer be possible to support certain postcss-plugin-specific syntax, invalid syntax or legacy syntax.
> [!WARNING]
> TODO: Move fork under `oxc-project` org and replace refs
- Use `oxc_formatter_graphql` from Oxfmt to handle `.gql` and `.graphql` files
- At point of this PR, gql-in-js is still handled by Prettier
As described in #23317, Prettier supports more syntax than ours, so for now fallback to Prettier when `oxc_formatter_graphql` failed to format.
NOTE: This fallback will be removed in later PR.
Fixes#20525, (thanks @oxura !)
```sh
# Many files that route to the Prettier `formatFile` callback and fail to parse
mkdir -p /tmp/repro
for i in $(seq 1 500); do printf '<template><div></template>' > /tmp/repro/broken$i.vue; done
# Run repeatedly with default concurrency
for run in $(seq 1 10); do node apps/oxfmt/dist/cli.js --write /tmp/repro; done
```
Within a few runs it crashes non-deterministically (exit codes varied: 133 / 138 / 139, and sometimes 2 = clean error report), with the same fatal as #20525:
```
# Fatal error in , line 0
# Check failed: object_ != kGlobalHandleZapValue. (or: node->IsInUse())
...
napi_reference_unref
<napi::error::Error as ...Drop>::drop
core::ptr::drop_in_place<napi::error::Error>
oxfmt::core::external_formatter::wrap_format_file::{{closure}}
```
Each broken file makes the `formatFile` callback reject; the resulting `napi::Error` is dropped on the TSFN await path and reaches `napi_reference_unref` during teardown → V8 fatal check.
After this fix (callback resolves errors as data), the same workload runs clean.
In Oxfmt, there is only one config file, but there were multiple conversion paths to the specific options used by subsequent formatters.
For example, it would generate `FormatOptions` for `oxc_formatter`, while assembling the necessary `JSON` for `prettier`.
There was a lack of consistency here, as some paths referenced the parsed `FormatConfig` while others referenced the raw JSON of `Oxfmtrc`. This inconsistency led to issues like the one mentioned in #21919.
In this PR, I have established `FormatConfig` as the single SoT, ensuring that all options are derived from it.
Fixes#20397
`can_collapse_whitespace()` walks the ancestor chain looking for `BinaryExpression(+)` to determine if boundary whitespace must be preserved.
The loop broke on the first non-`BinaryExpression` ancestor, so a `ConditionalExpression` (ternary) between the string and the outer `+` caused an immediate break. So, the `BinaryExpression` was never seen.
Prettier's `canCollapseWhitespaceIn()` iterates the entire ancestor path without breaking, reacting only to `BinaryExpression(+)` and `TemplateLiteral` nodes via if checks.
Fixes#20084, closes#20085
Currently, in the context of `js-in-vue`, there are 2 types of code paths:
- Script block: `run_full()`
- Converts a **string** formatted by `oxc_formatter` into Prettier's Doc format by splitting it into lines, joining with `hardline`
- Other cases: `run_fragment()`
- Converts the **IR** formatted by `oxc_formatter` into Prettier's Doc format through an IR -> Doc implementation
The current issue can be described as a bug in the former.
As a result of simply splitting by lines, newlines within strings (newlines within `TemplateLiteral`s) are also treated as `hardline` (which are affected by parent indentation, it should be `literalline`), causing the nesting to deepen with each format.
To fix this, the former code path now also goes through an IR -> Doc conversion process.
Additionally, by doing this, the `printWidth` is also handled correctly.
In #20085, which involves re-converting a formatted string into an AST and then traversing it, was deemed undesirable.
This doesn't seem to be an issue with native js/ts format paths, but it appears to cause problems when converting Prettier Docs, such as with gql-in-js.
Without this change,
```gql
type Mutation {
create__TYPE_NAME__(input: Create__TYPE_NAME__Input!): __TYPE_NAME__!
@skipAuth
```
will be formatted:
```gql
type Mutation {
create__TYPE_NAME__(input: Create__TYPE_NAME__Input!): __TYPE_NAME__!
@skipAuth
```
See trailing ` ` after `__TYPE_NAME__!`.
Add conformance test `assert(oxfmt(vueFile) === prettier(vueFile))`.
Currently, fixtures are downloaded individually and are not executed in CI.
It might have been better to change CI to download prettier's submodules and refer to them?, but for now.
### Overview
Part of #16608
This PR applies `oxc_formatter` to the js-in-vue section.
However, it is not complete and is only applied to the following parts within js-in-vue:
- `script` block
- and `generic="..."`
- `v-for` LHS
- `v-slot`
In the `script` block, `external_callback` is used like a regular JS file, but it isn't for others.
TL;DR: Now you can use sort-imports for Vue files.
### Review points
The points I'd like to ask your review are the following:
- Addition of `format_node()` to `oxc_formatter`
- Made it possible to process any type that implements `Format`, not just `Program`
- The implementation of `js-in-vue` fragment was separated as much as possible to avoid impacting existing code
- `oxc_formatter` IR to prettier `Doc`
### TODOs
- [x] Planning
- [x] Implementation
- [x] Check benchmark
- [x] Check coverage
- [x] Understand & refactor
- [x] oxfmt: JS side
- [x] oxfmt: Rust side
- [x] oxfmt: to_doc.rs
- [x] oxc_formatter: fragment_format
- [x] Check benchmark again
- [x] Check coverage again
- [x] Check ecosystem-ci
- [x] Tests 👉🏻#19563
Fixes#19264
The original issue only mentioned `modifiers`, but I've implemented `selector` as well.
While the original implementation also supports more attributes, I believe this is sufficient for now.
Fixes#18726
Support glob matching instead of prefix matching.
The original used regex, but there was no necessity for it, and this approach offers better performance.
In any case, it will be a braking change.
```js
// before: Matches react, reactify, react-router, etc
"elementNamePattern": ["react"]
// after: Matches react only
// before: Matches loot-core, loot-core/foo, etc
"elementNamePattern": ["loot-core"]
// after: Matches only loot-core, should update to
"elementNamePattern": ["loot-core/*"]
```
### Resolve issues:
* close: https://github.com/oxc-project/oxc/issues/18072
The new version of `prettier-plugin-tailwindcss` solved all root causes mentioned in the description of the above issue, see the commit history at https://github.com/tailwindlabs/prettier-plugin-tailwindcss/commits/main/
* close: https://github.com/oxc-project/oxc/issues/17972
* close: https://github.com/oxc-project/oxc/issues/18459
* close: https://github.com/oxc-project/oxc/issues/18628
These three issues are related to resolving the TailwindCSS configuration of that plugin, the new version decoupled with Prettier, and provides a public `createSorter` sorting API to `/sorter`, so that we can configure `base` correctly, which is the key for the plugin to resolve `stylesheet` and `config` from `base`.
### Key change on Oxfmt side
In this PR, the `stylesheets` and `config` options are normalized to absolute paths using the Oxfmt configuration directory before calling `createSorter` and delegating to `Prettier`.
The reason is as follows:
For formatting non-JS/TS files, Oxfmt delegates to Prettier. Therefore, we should continue using `prettier-plugin-tailwindcss` to handle this, ensuring that Prettier's configuration resolution remains intact. I made a change in [that plugin](https://github.com/tailwindlabs/prettier-plugin-tailwindcss/blob/125a8bc77639529a5a0c7e4e8a02174d7ed2d70b/src/config.ts#L50-L54) to prevent resolution when both `stylesheet` and `config` are absolute paths. This change is valid and could enhance the plugin's performance for both Oxfmt and Prettier users. The plugin needs to resolve the Prettier configuration to obtain the directory of the configuration file and join it with `stylesheet` and `config`. If they are already absolute, there is no need to join them.
### Benchmark
> Copy from https://github.com/tailwindlabs/prettier-plugin-tailwindcss/pull/438
Note: `new` means the current branch, `old` means the latest package in npm, so it includes a few optimizations that have already been merged into the main branch, not all in this branch.
Benchmark repo: https://github.com/dubinc/dub
```shell
Benchmark 3: oxfmt-new
Time (mean ± σ): 999.8 ms ± 32.1 ms [User: 8968.9 ms, System: 2246.7 ms]
Range (min … max): 977.2 ms … 1022.5 ms 2 runs
Benchmark 4: oxfmt-old
Time (mean ± σ): 1.628 s ± 0.027 s [User: 13.239 s, System: 4.980 s]
Range (min … max): 1.609 s … 1.647 s 2 runs
Summary
oxfmt-new ran
1.63 ± 0.06 times faster than oxfmt-old
```
Benchmark repo: https://github.com/tailwindcsslab/headlessui
```shell
Benchmark 3: oxfmt-new
Time (mean ± σ): 778.8 ms ± 28.9 ms [User: 7633.6 ms, System: 912.9 ms]
Range (min … max): 738.3 ms … 806.9 ms 4 runs
Benchmark 4: oxfmt-old
Time (mean ± σ): 1.033 s ± 0.034 s [User: 10.048 s, System: 1.454 s]
Range (min … max): 0.994 s … 1.073 s 4 runs
Summary
oxfmt-new ran
1.33 ± 0.07 times faster than oxfmt-old
```
Unfortunately...
Once override a built-in for `markdown`, it applies to all embedded formatting within that file!
This means that overrides occur with js-in-**vue**-in-markdown, and since we haven't addressed this yet, the code breaks.
````md
# MD
```vue
<!-- VUE -->
<script>
// JS
</script>
<template>
<li v-for="function _(IT_BREAKS_HERE 💥) {} in items"></li>
</template>
````
## Summary
- Remove the 30s timeout and associated comment from the first Tailwind CSS sorting test, added in #18339🤖 Generated with [Claude Code](https://claude.com/claude-code)
leaysgur