SvelteKit migration

[aabounegm]

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:

• [x] Move all files to the correct locations in SvelteKit convention, fixing imports and layout props accordingly
• [x] Remove Custom Elements support (SvelteKit is just not ready for them yet, and they weren't even working properly)
• [x] Replace any Sapper reference with SvelteKit
• [x] Fix GitHub Actions and pre-commit hooks
• [x] Investigate why some :global selectors are not working as they should
• [ ] Figure out what to do with theming and SCSS variables (related to #181 - should probably convert/open a discussion)

Additional 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.

• [x] Migrate everything to TypeScript
• [x] Turn off router and/or hydration for pages that don't need them 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.
• [x] Remove deprecated interfaces (only right and top props in Dropdown)
• [ ] Update documentation
  • [ ] Theming
  • [ ] Migration
  • [ ] Installation
  • [ ] Changelog

Blocking issues

• The PR is currently blocked by 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 why base: '/' is not allowed. Update: This turned out to be feasible. I was initially under the impression that kit.paths.base would add the base tag 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

• Forwarded slots (<slot name="loading-options" slot="loading-options">) are detected as taking a slot prop called slot in the generated types.
• Svelte Language Server (VS Code extension) does not understand import assertions (import pkg from './package.json' assert { type: 'json' }) even with latest Node.js installed Update: Doesn't matter any more since I moved the package import to vite.config.js

Closes #311

[github-actions[bot]]

Docs available on https://illright.github.io/attractions/349/

[metaory]

any updates on sveltekit migration"?

[aabounegm]

Hello @metaory, sorry for the delays from my side, but I just finished my final exams (at uni) today. I plan to come back to this issue soon, but I was also hoping to get more feedback on #360 first

[benmccann]

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 https://github.com/illright/attractions/pull/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?

[aabounegm]

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