Use Svelte 5 without migration #1283
Conversation
We'll fix the self-closing tags when we migrate to Svelte 5; in the meantime, we don't want these warnings to flood the compilation results and end up hiding other, more important, warnings.
This fixes the error about TypeScript enums not being natively supported
By making the .svelte-kit directory (produced by svelte-kit sync) part of the docker image in dev mode, we can avoid having the viewer build fail the first time, which causes the container to restart unnecessarily.
rmunn
force-pushed
the
chore/use-svelte-5-without-migration
branch
from
f2e8543 to
52a1c10
Compare
|
Looks like a bunch of Typescript errors and other fixups needed: the code compiles and runs, but |
* MaybePromise<T> = T | Promise<T> no longer exported from svelte-kit * svelte/store no longer exports Invalidator type (now () => void) * svelte-exmarkdown v4 needed for correct Svelte 5 component types * svelte-exmarkdown renderer prop needs casting as Component<any> so that Typescript won't complain about incompatible prop types * Components no longer have a .render method, instead you import the render function from Svelte and call it * svelte/compiler no longer exports walk, we're supposed to use estree-walker instead * estree-walker doesn't think nodes should have 'Element' type, as its types are designed for JS syntax trees, not Svelte component trees * Could not get Typescript to accept our componentMap in emails.ts, as each component had incompatible props. Punted by declaring its type as Record<EmailTemplate, any>.
|
After much effort, I finally got all the Typescript errors fixed up in
|
|
Linting currently failing with the following error: Error: Error while loading rule '@typescript-eslint/await-thenable': You have used a rule which requires parserServices to be generated. You must therefore provide a value for the "parserOptions.project" property for @typescript-eslint/parser. I'm not going to figure that one out today. @myieye - any ideas on how to tackle this one? Otherwise I'll see what I can do about it tomorrow. |
|
pushed a single change which tells taskfile to treat the pnpm workspace file as an input for cache invalidation. I tried it out and it works for me, there's some warnings in the logs about changing object and array params in non rune mode, but that's expected. |
This allows us to do the renderer plugin typecast just once rather than everywhere the Markdown component is used.
The remaining error is something we can't fix until we migrate our code to runes mode, so we'll turn it into a warning in a separate commit.
This isn't something we can fix until we migrate our code to runes mode, so we don't want to silence the warning but we don't want to turn it into an error either.
Some parts of the build were erroring out due to the .svelte-kit directory not being present. This should create that directory before the parts of the build that need it.
| @@ -26,7 +26,7 @@ | |||
| </Button> | |||
| <Dialog {open} on:close={toggleOff} class="w-[700px]"> | |||
| <div class="m-6 prose"> | |||
| <Markdown md={$text} plugins={[{ renderer: { a: NewTabLinkRenderer } }]} /> | |||
| <Markdown md={$text} plugins={[{ renderer: { a: NewTabLinkRenderer as unknown as Component } }]} /> | |||
There was a problem hiding this comment.
this should use the new markdown component
There was a problem hiding this comment.
The new Markdown component is in the lexbox frontend and I haven't implemented it in the viewer. I'll implement a copy of it in the viewer, because we might indeed end up wanting to use it more often.
There was a problem hiding this comment.
Done in commit fd453fb.
That way instead of having to do a Typescript cast every time we want to render Markdown that opens links in a new tab, we can do the cast once and just call a different component. We've done this already for the lexbox frontend code in src/, so we'll do the same thing for the viewer.
|
@myieye - I was having some trouble with Typescript types around the email template stuff, and had to change the code that pulls |
|
Per our team meeting we're going to deffer this until after the workshop in February |
Fix #1174.
This PR updates our Svelte dependencies to Svelte 5 and silences the compiler warning about self-closing HTML tags (the Svelte 5 migration script will take care of them for us, but in the meantime we don't want that warning to flood the compiler output and make us miss other, more important, warnings). Some Svelte-related dependencies have also been updated to a version that officially supports Svelte 5.
The sveltekit-superforms dependency was NOT updated, because sveltekit-superforms version 2 has breaking changes to its API and we're using an API from v1 that is not present in v2. The upgrade path from v1 to v2 should be simple, but it belongs in its own PR.