Duplicate slot name

[larryosborn]

Describe the bug
Using multiple slots with the same name is now an error. Previously in version 3.34.0 this would render the slots.

To Reproduce
The repl examples below are the same code, but with different svelte versions.

• Error in 3.35.0: https://svelte.dev/repl/f99436e1fcb44720a03dd6daef7c0843?version=3.35.0
• Works in 3.34.0: https://svelte.dev/repl/f99436e1fcb44720a03dd6daef7c0843?version=3.34.0

Expected behavior
With all the work recently on slots, I'm not sure if this would be a regression or intended behavior moving forward.

[j3rem1e]

This is described here : https://github.com/sveltejs/rfcs/blob/4efcda208abe007e6a786c18fd38377e25707589/text/0000-slot-attribute.md#2-disallow-more-than-1-named-slot-of-the-same-name

[larryosborn]

Slots can be rendered zero or more times, and can pass values back to the parent using props. The parent exposes the values to the slot template using the let: directive.

Svelte docs say a slot can be rendered zero or more times. Should naming a slot change that behavior? I'd hope this example is a use-case in favor of allowing multiple named slots.

[paulovieira]

With all the changes on slots I believe the docs are currently a bit outdated. It looks like there are breaking changes in v3.35.

But now it's possible to have components inside slots, using svelte:fragment. So maybe you can extract whatever logic you already have (with multiple slots) into a component. Examples here:

• https://github.com/sveltejs/svelte/blob/master/test/runtime/samples/component-svelte-slot/main.svelte
• https://github.com/sveltejs/svelte/blob/master/test/runtime/samples/component-svelte-slot-let-in-slot/main.svelte

[larryosborn]

Looks like the breaking change was mentioned in RFC comments about using duplicates.

Basically agree with this whole RFC but since some aspects are technically breaking changes we will probably need to just warn loudly for now, and continue with the current behaviour if someone does nest slots or have duplicates or whatever. Unless we choose to use the semver ju-jitsu of calling the changes a bugfix

[CherryDT]

In general the new <svelte:fragment> syntax is great and solves so many problems for me, thanks a lot for this improvement!

However, I also have to say I find it less than ideal to push a breaking change in a minor version update (violating semver spec) and on top of that not reflecting the change in the docs (the docs don't even mention <svelte:fragment> and instead still say slots can be repeated). Only because I ran into this error, googled it and then followed the links here to the (also not so easily discoverable) RFC and RFC comments and read through those threads I was able to understand what the change is and how the new functionality works. (It's not enough to look at just one place because the RFC talks about <svelte:slot> while later it became <svelte:fragment>, and in the middle there is also some talk about <svelte:template>.)

I by the way disagree with calling this a bugfix because it was documented before ("Slots can be rendered zero or more times" with no limitation for default slots). I understand the issue it caused with let conflicts, but due to the overall design of this feature there is just no way to fix that without breaking this, so it should have been left "unfixed" until the next major version upgrade (because this isn't really a fix in that shooting yourself in the foot will no longer harm your foot, but you are just taking the gun away so you can't shoot anything else either).

It would have been OK if the old syntax would still have worked and maybe just emitted a warning - then <svelte:fragment> would have been undocumented for the moment but no harm done because nothing broke, but with both disabling the old way in a minor version update and not documenting the new way I think it causes some unnecessary headache for developers.

My system for example uses duplicate slots heavily, and it would be a much smoother transition if I could refactor components that use this over time, with having both the old and the new way working at the same time for a while.

In my opinion the best thing to do now would be to bring back the old way with a warning and release that as 3.35.1, turning it back to an error only in 4.0.0.

[ganigeorgiev]

Just ran npm update and stumbled on this. I agree with @CherryDT. The change should have been only a warning.

In one of our older project we too use the previous duplicated slots behavior heavily and now we have to keep svelte to its last working version because we currently cannot dedicate the time to rewrite all our design system components at once with <svelte:fragrament>.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dummdidumm]

Closing as stale - this isn't gonna change