This is a POC of migrating a small but more involved codebase to Svelte 5.

Notes

• after bumping to Svelte 5 the app worked without any changes, though it has a few small bugs (see next section)
• wanted$derived.fn a couple of times because of big derivations (ex:Folder.svelte)
• wanted$effect.pre to run on the server, too, when converting some$: statements that were not reactive assignments
• being more familiar with runes syntax now I find the result more readable. Especially the differentiation of$derived and$effect is very helpful to understand better what kind of code I'm dealing with
• most migrations are generic, having automigration will help, it's rare that a change in behavior is introduced.$props() is the most tedious one (but also the easiest to automigrate)
• the "synchronize from props but also update from above" situation occured inMenu.svelte
• the "this needs to be$state" warning was very helpful in converting the right variables / not forgetting it
• the "State referenced in its own scope will never update" warning was sometimes overzealous, for example when passing a proxied state to context when I know it's only the properties that are meant to be used reactively. But I think it will help greatly in other situations, so it's probably fine
• converting stores to state objects required a bit of per-case thinking because the whole object isn't reactive, only its parts are. Withwritable there was a fixed contract making you think less about this because the container was already there. I ended up moving most separatewritables into one big$state object because I don't have the "how to encapsulate it" problem then. This feels natural for state that belongs together but for primitive state you always have to think a bit how to do it. Usage-wise it didn't feel much different to stores, although doingx.set(newValue) feels a bit nicer compared tocontainer.x = newValue, which feels hacky because you're mutating stuff all over. That could just be me though, and in a certain way it might even be good because the hackyness of modifying stuff from everywhere without hiding it behind a proper method that changes things is more obvious that way - though it isn't as easy to forbid writing to the state because there's no way to mark something as readonly for the outside but have it be regular$state within the same scope.
• migrating towards event attributes was straightforward. In some cases it revealed workarounds (the payload being an object with one property on it, so that you can writee.detail.theName to know what you're dealing with which can now be simplified to justtheName). In one case I had to add$props() because of event forwarding, which felt a bit more boilerplatey to write but afterwards it's much clearer what the component's in/outputs are because I can just scan for the$props() rune. In that instance I also had to add thechildren prop because it was receiving<slot /> content which was a bit confusing for a moment, maybe language tools can make it more clear what's going on there. Speaking of: I found the syntax highlighting to be worse, we should maybe highlight the attributes starting withon differently, and we definetly should add semantic highlighting to them.

Overall the migration was pretty straightforward, with a few gotchas which depending on your app could happen more or less frequently. The new code reads better overall to me, though not really much has changed, especially in the template (which is a good thing I'd say!)

Bugs

• SvelteKit:afterNavigate doesnt fire initially, becauseonMount is async now (result: editor doesn't show code contents for initial load); we need to callflushState() in the backwards compatibility wrapper or in SvelteKit
• folder tree: new file -> doesn't autofocus
• Svelte/SvelteSplitPane: resizing doesn't work properly. In Svelte 4,bind:this triggers an update that is flushed in the next tick, in Svelte 5 it's synchronous. This results in one update in Svelte 4 with height/width set but two updates in Svelte 5 with the first having no width/height set yet, resulting in a too low calculation and therefore rendering the editor too small. I don't think we can fix this in Svelte 5 due to the timings, so the fix needs to happen in SvelteSplitPane (arguably it revealed a proper bug in the library)
• Svelte: The file toggle doesn't work anymore when using$state instead of awritable, I don't know why. It's proxied state, so its parts should be reactive