fix(oxfmt): use literalline for template literals in textToDoc#20085
Closed
vinayakkulkarni wants to merge 1 commit intooxc-project:mainfrom
Closed
fix(oxfmt): use literalline for template literals in textToDoc#20085vinayakkulkarni wants to merge 1 commit intooxc-project:mainfrom
vinayakkulkarni wants to merge 1 commit intooxc-project:mainfrom
Conversation
7032f60 to
52b611b
Compare
When `vueIndentScriptAndStyle: true`, Prettier wraps the `textToDoc()` result with `indent()`. Template literal newlines joined with `hardline` would respect this indent, causing +2 spaces per format pass (infinite indentation growth). Re-parse the formatted output to identify `TemplateElement` spans and use `literalline` (which ignores parent indent) for newlines within template literals, while keeping `hardline` for all other newlines. Closes oxc-project#20084.
52b611b to
49c2309
Compare
graphite-app bot
pushed a commit
that referenced
this pull request
Mar 12, 2026
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 file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #20084
When
vueIndentScriptAndStyle: true, formatting template literals inside Vue SFC<script>blocks is non-idempotent — eachoxfmt --write .pass adds +2 spaces of indentation to template literal content, growing infinitely.Root Cause
In
run_full()(text_to_doc_api.rs), the formatted code was converted to a Prettier Doc by joining all newlines withhardline. When Prettier wraps thetextToDoc()result withindent()forvueIndentScriptAndStyle,hardlinerespects the parent indent — so template literal text content gets +2 spaces per pass.Fix
After formatting the code to a string (preserving all formatting decisions), re-parse the output to identify
TemplateElementspans via an AST visitor. Then build the Prettier Doc using:literallinefor newlines inside template literal spans (ignores parent indent)hardlinefor all other newlines (respects parent indent, as before)This matches how Prettier itself handles template literals in its own
textToDocpath.Changes
apps/oxfmt/Cargo.toml— Addedoxc_ast_visitdependencyapps/oxfmt/src/api/text_to_doc_api.rs— Call new function instead ofprinted_string_to_hardline_docapps/oxfmt/src/prettier_compat/to_prettier_doc.rs— Addedprinted_string_to_doc_with_template_literals(),TemplateElementCollectorvisitor, removed oldprinted_string_to_hardline_doc()apps/oxfmt/test/api/js-in-vue.test.ts— Added idempotency testReproduction
https://github.com/vinayakkulkarni/oxfmt-template-literal-repro
Verification
cargo c✅cargo c --no-default-features✅cargo c --features detect_code_removal✅cargo clippy -p oxfmt✅cargo t -p oxfmt— 32/32 passed ✅pnpm build-test && pnpm t— 241/241 passed ✅