feat: npx svelte-migrate self-closing-tags

[Rich-Harris]

Companion to sveltejs/svelte#11114. This adds an npx svelte-migrate self-closing-tags migration that replaces all the self-closing non-void elements in your .svelte files.

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 61c07c2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte-migrate	Minor

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

[Rich-Harris]

The lint failure here is caused by a battle between this and Prettier, which turns <slot></slot> back into <slot />. I'm not sure why that's happening — prettier-plugin-svelte is supposed to ignore closing tag style as of version 3 — but we'll need to get to the bottom of it before we can release this.

[jrmajor]

@Rich-Harris Fixed in sveltejs/prettier-plugin-svelte#435.

[Rich-Harris]

Fantastic, thank you! Updated the migration task to prompt people to upgrade — as soon as it's released, we'll bump the prettier-plugin-svelte version used in this repo and release this

[Conduitry]

We should ideally figure out why we now have simultaneous two versions of esbuild as of this PR.

edit: And two versions of Rollup.

edit: And two versions of Svelte.

[Rich-Harris]

i have absolutely no idea

[Rich-Harris]

downgrading prettier-plugin-svelte back to the previous version doesn't seem to change anything

[Conduitry]

The two versions of esbuild, at least, appears to be because we upgraded Vite in this PR (probably unnecessarily), which depends on a newer version of esbuild - but other things, like some adapters, still depend on the old version.

[Conduitry]

I've taken the liberty of pushing 3148f19 - let's see how this looks now.

[Conduitry]

I think that looks good? For posterity, what I did was grab an old copy of pnpm-lock.yaml from main, run pnpm install again, and commit that.

[Rich-Harris]

yeah, aside from the random failing test — investigating

[Rich-Harris]

The failing test relates to this file:

kit/packages/package/test/fixtures/typescript-esnext/src/lib/Plain.svelte

Lines 6 to 12 in 3148f19

	<svelte:head>
	<script type="application/ld+json">
	{
	JSON.stringify(jsonLd);
	}
	</script>
	</svelte:head>

Looks like sveltejs/prettier-plugin-svelte#424 introduced a change to how JSON+LD scripts are handled — they are now assumed to contain JSON and formatted as such. The test seems to assume that the contents of these elements are treated literally (i.e. not interpolated) which is wrong. Will update the test.

[benmccann]

We should ideally figure out why we now have simultaneous two versions of esbuild as of this PR.

Just FYI, we have two on main since adding better Cloudflare support recently because wrangler is stuck on an old version (cloudflare/workers-sdk#5222).

edit: And two versions of Rollup.

I sent #12118 to upgrade vite, vitest, rollup, and esbuild (minus the version being pulled in by wranger, which we can't do anything about)

[dummdidumm]

This is too broad:

• doesn't leave foreign namespace alone
• forces slot expansion even if those tags are not really real html tags, Svelte hijacks them to mean something different and as such self closing should be allowed. If we don't do that then I think the migration will produce a lot less noise for a piece of syntax that is deprecated anyway

[Rich-Harris]

What foreign namespaces are we talking about? MathML? I'm not aware of any MathML elements that make sense without child content. Are people using other namespaces in Svelte components? The worst case scenario is we replace <valid /> with <valid></valid>. It would overcomplicate things to an absurd degree if we tried to avoid that.

Similarly, to distinguish between real <slot> elements and fake ones, we would need to determine whether a given .svelte component was intended to be compiled as a custom element, which... I don't know, I guess we would need to traverse the project looking for a svelte.config.js file (and miss cases where config was set directly via a bundler plugin) or something? And then we'd have <slot /> in some places and <slot></slot> in others and we'd need to explain why that was the case.

Seems like a bad use of time and energy!

[dummdidumm]

• I'm talking about the namespace=foreign compiler option, which is used for Svelte Native etc. . Changing their code is just unnecessary.
• For custom elements we just need to see if there's a customElement or tag option on svelte:options.
• Finding a svelte.config.js is really easy and was done in various migration scripts before.
• avoiding the slot thing will make the whole migration a lot less noisy and be accepted by more people.

Getting a migration script correct is a good spend of our time!
I can do the adjustments if you want to.

[Rich-Harris]

closing in favour of #12128