Aim to enable the use of existing Prettier plugins like prettier-plugin-svelte.
The current ecosystem primarily consists of two types of plugins.
- For supporting files not supported by Prettier (original motivation of plugin)
prettier-plugin-svelte, prettier-plugin-ruby, etc
- For overriding behaviors already handled by Prettier
prettier-plugin-sort-imports, prettier-plugin-tailwindcss, etc
This issue is addressing the former one.
Regarding the latter, since JS/TS files are formatted by oxc_formatter, we need to consider how to handle this. For sort-imports, implementation has already begun on the oxc_formatter side.
However, we want to keep it usable for files like Svelte or Vue, etc.
Original plan
Plan
- JS: Update napi function
setupConfig to return { parsers, extensions, filenames }[]
- Load plugins, parse
languages and return them
- Need to search
overrides too, plugins may only appear later
- Rust: Allow that
languages in support.rs and call Prettier with parser
- JS: If possible, loads plugin only for targeted file
(Need to support (astro|svelte)-in-js?)
Consideration
- Plugins often rely on
prettier internally
- We are bundling
prettier in oxfmt
- But if bundled, plugins cannot find our bundled
prettier
- This means extra
prettier install needed to work
We should stop bundling prettier?
- Choice1: Require users to install extra
prettier if they want to use prettier-plugin-xxx
- = 2 copy of prettier, 1 for
oxfmt (and bundled tailwind), 1 for prettier-plugin-xxx
- Choice2: Bundle prettier-plugin-xxx like we did for tailwind
- Only major plugins should be bundled
- Choice3: Stop bundling and add
prettier as deps
- Bad for some people who still using both
prettier and oxfmt
- 2 copy of prettier may cause issue
- Choice4: Stop bundling and add
prettier as peerDeps
- Good for some people who still using both
prettier and oxfmt
- But many people may think "Why do we need
prettier to use oxfmt?"
Past experiments
- Bundle
prettier-plugin-xxx and always collect .xxx
- Re-export
prettier internal API and vendor prettier-plugin-xxx and always collect .xxx
- Externalize
prettier dep and handle many plugins dynamically
UPDATE
While experimenting some ways to make it possible, but we're looking for a better way to solve in long term.
Aim to enable the use of existing Prettier plugins like
prettier-plugin-svelte.The current ecosystem primarily consists of two types of plugins.
prettier-plugin-svelte,prettier-plugin-ruby, etcprettier-plugin-sort-imports,prettier-plugin-tailwindcss, etcThis issue is addressing the former one.
Regarding the latter, since JS/TS files are formatted by
oxc_formatter, we need to consider how to handle this. For sort-imports, implementation has already begun on theoxc_formatterside.However, we want to keep it usable for files like Svelte or Vue, etc.
Original plan
Plan
setupConfigto return{ parsers, extensions, filenames }[]languagesand return themoverridestoo,pluginsmay only appear laterlanguagesin support.rs and call Prettier withparser(Need to support (astro|svelte)-in-js?)
Consideration
prettierinternallyprettierinoxfmtprettierprettierinstall needed to workWe should stop bundling prettier?
prettierif they want to use prettier-plugin-xxxoxfmt(and bundled tailwind), 1 for prettier-plugin-xxxprettierasdepsprettierandoxfmtprettieraspeerDepsprettierandoxfmtprettierto useoxfmt?"Past experiments
prettier-plugin-xxxand always collect.xxxprettierinternal API and vendorprettier-plugin-xxxand always collect.xxxprettierdep and handle many plugins dynamicallyUPDATE
While experimenting some ways to make it possible, but we're looking for a better way to solve in long term.