Support svelte 5

[baseplate-admin]

Describe the problem

Hi, is it possible to support svelte 5?

Describe the proposed solution

Svelte 5 is not supported it seems

Alternatives considered

uh, there exists no alternative

Importance

i cannot use svelte-retag without it

[patricknelson]

Right now: No, since it's still unstable and actively under development (at time of writing). However, we can at least anticipate what's coming up with some of the public API breaking changes here: https://svelte-5-preview.vercel.app/docs/breaking-changes

Summarizing what I found so far (for future reference):

It looks like a new major version of svelte-retag will also be required (setup v2 milestone) as some of the breaking changes would cascade down to anything depending on this package, too. That is: It'll likely only be compatible with either Svelte v3/v4 or Svelte v5, and that's mainly due to v5's use of mount() instead of new to instantiate components. Also, I got a basic version of this working pretty quickly with v5 for the hello world demo, but after testing the vercel demo site it became clear that some other important features will need quite a bit more time to hash out (mainly issues with light DOM nesting, but there could be more). I put all this in experimental-svelte-v5 for now (see 1812b99); it's not ready for a PR yet though.

That's just what I could find after some initial testing. There might be more, especially once it's released. So, based on this, we'll definitely need to wait for the dust to settle with a stable svelte@^5.0.0 before there can be a svelte-retag@^2.0.0 released to support it.

[patricknelson]

p.s. Forgot to mention that as part of my testing in experimental-svelte-v5 branch, I went ahead and rolled out #27 as a minor/patch fix, which was necessary to address some obvious bugs that came up when testing v5. It works with Svelte v3/v4, so it made sense to just roll that into main immediately (as svelte/internal isn't a public API anyway, as the name implies).

[baseplate-admin]

Hi, Thanks for the amazing work.

---

Forgot to mention that as part of my testing in experimental-svelte-v5 branch, I went ahead and rolled out #27 as a minor/patch fix, which was necessary to address some obvious bugs that came up when testing v5. It works with Svelte v3/v4, so it made sense to just roll that into main immediately (as svelte/internal isn't a public API anyway, as the name implies).

Sounds awesome yep using private api will eventually lead to breakage.

That is: It'll likely only be compatible with either Svelte v3/v4 or Svelte v5, and that's mainly due to v5's use of mount() instead of new to instantiate components.

It can check for internal version and support both v3+v4 and v5. Here is the relevant file in svelte repository that exposes svelte version.

But it will inevitably increase the complexity of the entire package ( which might not what we want )...

it became clear that some other important features will need quite a bit more time to hash out (mainly issues with light DOM nesting, but there could be more). I put all this in experimental-svelte-v5 for now (see 1812b99); it's not ready for a PR yet though.

Thanks for taking a look into this on such a short notice :D

---

overall i am not sure svelte 5 is what i envisioned svelte to be. but it is what it is...

[patricknelson]

It can check for internal version and support both v3+v4 and v5. Here is the relevant file in svelte repository that exposes svelte version.

In this case, my key concern is just that I don’t think there’s any way to avoid it being a breaking change (regardless of the approach taken) making it necessary to go v2, that’s all. If we made it conditional and changed to an async import, that would affect builds/bundlers. For example, one key feature is support for IIFE for fast/early immediate execution of Svelte during initial render to eliminate CLS (cumulative layout shift). In other words, may as well just keep it simple and support one major API at a time (i.e. v3/v4 or v5) and then simply put a stake in the ground and call that v2 for now. 😊

[patricknelson]

Quick note: While this is currently assigned to v2 milestone (as a breaking change), it could be bumped to later version since I don't want it to block other changes slated for release with v2, largely because I will not be able to really work on this until after Svelte 5 is stable (as noted above).

[patricknelson]

Sorry for the turmoil! Copying my comment from #20 (comment):

Hmm... sorry folks, still figuring this out! 😅

I need some way to classify something as a breaking change (and thus must be in a future version) but also want a clear way of communicating what will definitely make it into the next version (i.e. sort of like approved for v2 and v3, etc). So for now it cannot be v1 but I'm not sure it'll make it into v2 either, so I'll create a new "one day" milestone instead.