SvelteKit migration #349
SvelteKit migration #349
Conversation
This is a mega-commit since everything is tied together (it is a framework migration after all), but it mostly consists of renames and minor adjustments. This includes the following: - Move files to the appropriate locations for SvelteKit - Change any "attractions" imports in docs to use "$lib" - Define aliases in CSS without a custom importer (for client usage) - Move SCSS of component docs (`.svx` files) into the component itself (path aliases didn't work here) - Remove clipboard-polyfill
When segment is an empty string
Using the RegEx `\* @type \{([\S\r]*)\}\s+(\*\/\s+export let \w+);` with replacement `$2: $1;`
Using the RegEx `\* @type \{(.*)\}\n.*(\s+export let \w+Class)` with replacement `*/$2: $1`
that cannot be trivially inferred Using RegEx `\* @type \{(.+)\}\s+\*\/(\n\s*export let \w+) =` replaced with `*/$2: $1 =`
Mainly in local variables and function parameters and remove empty JSDoc comments
Mostly just type-casting, ensuring compatibility, and making use of flow analysis with type guards
update Sapper references
And `ComponentProps` as well
aabounegm
force-pushed
the
sveltekit-migration
branch
from
616b950
to
af3013f
Compare
|
any updates on sveltekit migration"? |
|
Is there anything you're blocked on in terms of getting this in? I feel like this task has maybe become too large. I think migrating only the docs first as #312 was doing might have been more approachable vs trying to boil the ocean. But given how much progress has been made with this approach, maybe it could just be merged with a few things broken and some cleanup can happen later? |
|
Well, the main issue is that both maintainers (me and @illright) got busy with other things in their lives, be it study or work or both. Still, I wanted to continue with the migration because it didn't seem so difficult. The main stopping point was #360, in which we decided to move away from Sass to CSS with variables (custom properties), but SCSS/CSS are not really my strong point. I did some work in the sass-migration branch but it's far from complete. TL;DR: I need to muster up some energy to continue the CSS migration and the rest should be straightforward |
A previous PR (#312) was made with the target of rewriting the docs in SvelteKit. It quickly became outdated and was only targeting the docs, so this PR supersedes it since it started from a fresh SvelteKit template and targets the entire app (not just docs).
Important tasks
The migration is large and some of the tasks may be split into other smaller PRs. The general outline of the tasks is as follows:
:globalselectors are not working as they shouldAdditional tasks
These are the nice-to-haves that theoretically shouldn't block the migration to SvelteKit, but also make use of some features that were not possible/easy before.
Hydration is required for all pages (at the very least, for the "Components" dropdown to work), and in that case there is no compelling reason to disable the router.
rightandtopprops inDropdown)Blocking issues
The PR is currently blocked by Setting paths.base in svelte.config.js causes adapter-static to fail (404) sveltejs/kit#4528 and the{base}/...workaround is not practical. Some links cannot be transformed that way (ex: ones inside CHANGELOG.md). Since<base href="/" />is allowed (and actually fixes the problem), I'm wondering whybase: '/'is not allowed.Update: This turned out to be feasible. I was initially under the impression that
kit.paths.basewould add thebasetag as Sapper did, but that turned out to not be the case. It was definitely tiresome but possible to update all URLs everywhere.Other issues
<slot name="loading-options" slot="loading-options">) are detected as taking a slot prop calledslotin the generated types.import pkg from './package.json' assert { type: 'json' }) even with latest Node.js installedUpdate: Doesn't matter any more since I moved the package import to
vite.config.jsCloses #311