• feat(oxfmt): Update lsp language_id for svelte #19954
• feat(oxfmt): Update --migrate for svelte #19953
• test(oxfmt): Add svelte conformance #19952
• feat(oxfmt): Support .svelte file #19807 👈 (View in Graphite)
• main

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

This stack of pull requests is managed by Graphite. Learn more about stacking.

Small difference related to svelteStrictMode, which will be always true

Can you elaborate? We're about to remove svelteStrictMode in the next major of prettier-plugin-svelte. The behavior will be:

• Non-void tags are now always done formatted to open+closing tag, e.g. <div /> will be formatted <div></div>
• Quotes around expressions are always removed, because in the future Svelte may treat this as a string, e.g. <div class="{foo}"></div> will be formatted to <div class={foo}></div>

Thank you for the confirmation! 🙌🏻
Let me explain the situation briefly...

• Initially, I mistakenly believed that in order to bundle prettier-plugin-svelte into oxfmt, its dependency svelte/compiler also needed to be bundled
• And to bundle it, a specific version had to be chosen
• So, I was investigating what problems would arise if I bundled the latest v5, and that's how I arrived at this conclusion
• However, we later realized that it could actually be kept as a peer dependency

Given this, my understanding is that there are no longer any particular concerns now.

As I confirmed in original issue, if supporting only Svelte 5 is acceptable, then not supporting this option at all could also be considered.

Only supporting Svelte 5 is totally acceptable. Probably makes your lives a bit easier (you can start using the modern AST right away instead of having to adjust that code in a few years when the legacy AST is gone), and also incentivises people more to upgrade to Svelte 5, which is in our interests.

As for "what is the modern AST" - I've just put up a PR that switched to the modern parser format, there you can see the difference (it's mostly renaming of nodes and how the children are represented on the blocks/elements): sveltejs/prettier-plugin-svelte#512
You need to call parse like that to get the modern AST: parse(input, { modern: true }). This will be the default at some point, and at some point the old AST will be gone.

In that sense, our use case is not calling parse() but simply to register it as a plugins for Prettier.
https://github.com/oxc-project/oxc/pull/19807/changes#diff-8ac9a85e5c4cea1945edd39de3b5cfb0e510210af8a1f1d7dd3397e65d3f3f0aR181

It seems there isn't such an option, so if we only want to support modern ASTs, I think we'll have to wait for the v4 release of the prettier-plugin-svelte itself. (right?)

I think we can either wait for that, or release it soon as is. (The work is already complete).
What do you think?

Not having Svelte support is currently the only blocker for us in adopting oxfmt.
We're also stuck on Svelte 4, due to some breaking changes in other dependencies.

So it would be great if we could get Svelte 4 support in oxfmt, as the work is already done.

Oh I didn't realize that you basically only setup a bridge to JS-land here and just use prettier-plugin-svelte. In that case you can go ahead now, because as I understand it you can just bundle a new version of prettier-plugin-svelte once we release the new major - or is even that not required and it's just a peer dependency in the sense of "user installs it"?

In that case you can go ahead now, because as I understand it you can just bundle a new version of prettier-plugin-svelte once we release the new major - or is even that not required and it's just a peer dependency in the sense of "user installs it"?

We don't plan to bundle svelte/compiler, but we do intend to bundle prettier-plugin-svelte. (due to internal implementation)

And if we were to bundle a backwards-compatible plugin at this point, a major update to that plugin would become a breaking change for Oxfmt, which we want to avoid.

We're fine with waiting for the next version of the plugin to be released, but do you have an ETA? (Apologies if that's a difficult question to answer. 🙇🏻)