feat: add Svelte 4 migration#9729
Conversation
🦋 Changeset detectedLatest commit: a134b95 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
looks like the if we find |
This is purely about the migrate package for now, we should do the compatibility thing once we're sure that actually works. Can I has approval pleez? 😄 |
benmccann
left a comment
There was a problem hiding this comment.
This is purely about the migrate package for now
Yeah. I'm suggesting lots of projects (i.e. libraries) have peerDependencies, which will need to be updated and we should probably handle that for them
| * @param {string} code | ||
| */ | ||
| function update_transitions(code) { | ||
| return code.replace(/(\s)(transition:|in:|out:)(\w+)(?=[\s>=])/g, '$1$2$3|global'); |
There was a problem hiding this comment.
per dominik's suggestion on Discord: this might be tedious to undo and most people probably won't want |global even if that's the same behavior as svelte 3. maybe either remove it or make it an option
| for (const file of files) { | ||
| if (extensions.some((ext) => file.endsWith(ext))) { | ||
| if (svelte_extensions.some((ext) => file.endsWith(ext))) { | ||
| update_svelte_file(file); |
There was a problem hiding this comment.
this would break with mdsvex .svx , safer to only do .svelte by default and maybe ask the user for other extensions that contain svelte code that is compatible with the basic regex used in update_svelte_file
There was a problem hiding this comment.
I commented that out because I think it's going to do more harm than good since .svx is probably the most common usage of it
|
Is there a separate documentation that explains to the user which code mods are being done, possibly with examples referencing the breaking changes that made them needed? I understand this is a pretty basic tool, but at the same time we are going to have a larger use for this with svelte-5, and it is going to be used by a lot more people than the sveltekit migrations. So some attention to UX would go a long way to avoid getting clogged with questions about it |
|
In my opinion that should be part of the migration docs we need to write. "These are the breaking changes, the following are migrated automatically, here's some examples (links to PRs for more details" - sth like that |
|
we could potentially add docs on svelte.dev. @PuruVJ made a placeholder page for it: https://svelte-dev-2-75m8guw4t-svelte.vercel.app/docs/migrating-v3-to-v4 we're aiming to try launching the site at the same time as svelte 4. we could flesh out that page a bit if folks think it's a good idea and a good place to host it |
|
I noticed this package uses |
WIP, depending on what else we can migrate
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.