Svelte 5 Migration Plan

[stricklandrbls]

Overview

Attempting to migrate to Svelte 5 has been a long and complex task given that the Data Editor being 2 major versions behind the latest Svelte version. I wanted to share some ideas for resolving the issues that I've seen as well as propose a discussion for a plan to migrate the Data Editor UI to utilize Svelte 5.

Discussion Topic 1: Root-level Replacement of Webpack w/ Vite

While investigating resolutions for apache#970 (Svelte 5 Migration), I noticed that Svelte essentially expects developers to exclusively utilize Vite for packaging projects that utilize Svelte with the release of Svelte version 4. This is mostly due to the fact that most Svelte projects are built for hosting on a web-server which Vite packages quite nicely.

I had a discussion w/ @shanedell about my concerns with utilizing two separate packaging services within the same project. This also coincides with the previous concerns I held about the project when it had a mix usage of npm and yarn.

We came to the conclusion that it would be beneficial to replace webpack with Vite for the entire project. I'm looking for additional thoughts and concerns related to this.

Discussion Topic 2: Svelte 5 Migration Plan & Current Issues

I got to a point in the Svelte 5 migration where I could utilize Svelte 5 features & syntax but only if I used Vite to package. Webpack seems to emit a ton of unrelated and, frankly, convoluted error messages that prevents the package.json scripts to build, package, and test the Data Editor.

A major feature for Svelte 5 is the ability to have .svelte files run in a 'legacy' mode ¹ which allows older Svelte versions to execute while having the project run on Svelte 5. This is a fantastic feature for migrating the Data Editor. However, I believe we'll need a migration plan for the Data Editor given that the Data Editor's UI source is so large and the Svelte 5 syntax is significantly different from the current version (Svelte 3).

My initial thoughts for a migration plan would be:

1. Determine which .svelte component files contain the least amount of effort to migrate.
   a. Effort, in terms of the Data Editor, would be mostly defined by the amount of legacy svelte 'stores' used within a component. This is due to the deprecation of the 'stores' functionality when migrating from Svelte 3 to 5 ²
2. Create issues within GitHub for tasks for migrate portions of the .svelte files.
   a. The amount of issues and which components are assigned per issue will be a part of the result from step 1.
3. Determine when certain components can be appropriately migrated and the assigned issue worked.

Conclusion

I'd love to hear everyone's thoughts, concerns, and additional ideas related to these topics. I do believe that some of these features could become a part of the 1.4.2 release.

@shanedell @scholarsmate @JeremyYao @naga-panchumarty @michael-hoke @hdalsania
Tagging here because I think I lost the ability to add additional participants for the ctc-oss fork

---

Footnotes

1. https://svelte.dev/docs/svelte/legacy-overview ↩

2. https://svelte.dev/tutorial/svelte/stores ↩

[rthomas320]

The TDML editor uses webpack for packaging also, but I don't think it uses svelte. Would we be able to use webpack for the TDML editor and Vite for the Data Editor? Or would all web packaging need to convert to Vite simultaneously? I think the launch wizard and unit tests are also using webpack for packaging.

[stricklandrbls]

We discussed converting all web packaging to Vite given that it is relatively non-trivial.

I'm a firm believer in being "minimally microserviced" so having a single web packager for the entire project makes things simpler and more orthogonal. Emphasis on the orthogonality because it still baffles me how I could package the Data Editor w/o errors in Vite and have the extension display the Data Editor correctly but when used with Webpack it emits errors that prevent packaging.

[scholarsmate]

I believe the desire is to use one technology for the entire project for packaging. We used rollup.js for the DataEditor (which was simpler and faster), but switched to webpack as that's what the rest of the code used. If @shanedell and @stricklandrbls are good with migrating the entire extension over to vite, then I'm good with it.

VSCode and the JetBrains IDEs have good support for vite as well, plus it's more modern than webpack with less of a learning curve. webpack has been a bit of beast, for me at least.

[stricklandrbls]

... plus it's more modern than webpack with less of a learning curve. webpack has been a bit of beast, for me at least.

Webpack, for me, is one of convoluted tools that I feel I should learn just to convey to others about why tools like Vite are a better option.

[stricklandrbls]

Current Svelte 5 Migration State

Here is a the current Svelte 5 Migration branch for the Data Editor: https://github.com/stricklandrbls/daffodil-vscode/tree/dataeditor-svelte5-upgrade

There is a lot of cleanup that needs to take place but this branch demonstrates the usage of Svelte 5 with the Data Editor's current Svelte 3 source. The steps the start the Data Editor have not changed.

Current Breaking Issue

When the Data Editor is started Omega Edit always fails to create the viewport for the selected file. Going to investigate this further when I get some spare time.

---

This is incredible progess for the Data Editor even with this breaking viewport issue 🎉🎉🎉

[stricklandrbls]

Update

The breaking issue listed above has been resolved and the Data Editor, so far, seems to be working as normal!

[stricklandrbls]

Vite Replacement

Another update for the project moving to Svelte5 w/ Vite.

I was able to build and package the entire project in dev mode and successfully launch the Extension launch config to execute the extension.

These changes reside in the latest commit for this branch https://github.com/stricklandrbls/daffodil-vscode/tree/dataeditor-svelte5-upgrade