Backward compatibility, even after migration

Describe the problem

Svelte 5 remains compatible with Svelte 4 components by allowing the use of old syntaxes (slots, on:event directive). That's fine because it's will not break existing code, and this does not force a full migration which could be complex on large projects.

But there a catch : as soon as a Svelte 4 component is migrated to a Svelte 5 syntax, all files that use it must also be migrated to the new syntax :

Svelte's 4 named's slots will be silently ignored.
The on:event directive may be broken (depending on how it is managed within the component)

This is a breaking change that will force users of the component to migrate their own code, and which could push developers not to migrate their libraries...

I think it should be possible to migrate a Svelte 4 component to Svelte 5 syntax, while maintaining backward compatibility with existing code.

Slots

The default slot is managed properly, but they are some use-cases that can be problematic and break compatibility :

<slot name="header" /> should be converted into {@render header?.()}. But any use of <div slot="header">...</div> will be completely ignored !
<slot prop1={value1} prop2={value2}/> should be converted into {@render children?.(value1, value2)}. But any code that use <Component let:prop1 let:prop2> will now throw an error. In addition, the let: directive are managed differently from snippet parameters, and it should be translated.
<slot name="info"/> may have a conflict name with an existing props with the same name. So we may opt to a different name for the snippet, witch cause a breaking change.
We can even have both, like <slot name="footer" {copyright} {year}/> that need to translate parameters and use a different name.

Events

For events, I see 2 use-cases that might cause problems :

Migrating event's forwarding with on:click Currently event's forwarding is handled via a legacy bubble() function, but :
- this add the handler even when it's not defined by the caller.
- It's a new APIs which pollutes the code, and which will have to be deleted in the future.
- In some case it will only accept on:click but not onclick...
Migrating events dispatched via createEventDispatcher() Currently this would only support the on:event={fn} directive, but not the onevent={fn}. This must be rewritten to adopt Svelte 5 syntax.

Describe the proposed solution

It would be great to be able to write these components with Svelte 5 syntax (snippets and onevent handlers), while maintaining compatibility with existing code that might use the new syntax.

I think the solution could be through metadata, which would indicate how to make the transition between the old syntax and the new one. Maybe by using a $legacy runes?

This rune will contains two information for each slot

Exemple :

$legacy({
    slots: {
        // Support for `<slot name="header" />`
        // Replaced by `{@render header?.()}`
        header: true,

        // Support for `<slot prop1={value1} prop2={value2}/>`
        // Replaced by `{@render children?.(value1, value2)}`
        // The name of the properties passed to the slot
        default: ['prop1', 'prop2'],

        // Support for `<slot name="info"/>` with a new name
        // Replaced by `{@render infoTemplate?.()}`
        // The slot "info" will be mapped into the new prop snippet "infoTemplate"
        info: "infoTemplate",

        // Support for `<slot name="footer" {copyright} {year}/>` with a new name
        // Replaced by `{@render footerTemplate?.(copyright, year)}`
        // The slot "footer" will be mapped into the prop snippet "footerTemplate"
        footer: {
            // Name of the snippet :
            prop: "footerTemplate",
            The name of the properties passed to the slot
            args: ['copyright', 'year']
        }
    },

    events: {
        // on:click while be mapped into the `onclick` prop
        'click': true,
        // on:customevent will be mapped into the `onfire` prop
        'customevent': 'onfire'
    }
});

How would this work?

When the component is initialized, the props will be filled with the data from $$props and $$events according to the rules defined in these metadata. So the component could use Svelte 5 syntax internally, however it is used.

In the same way, createEventDispatcher() should use this metadata in order to use props instead of $$events. So something like this :

    const dispatch = createEventDispatcher();

    dispatch('notify', 'detail value');

should be equivalent to :

    let { onnotify } = $props();

    onnotify?.('detail value');

Importance

nice to have

sveltejs / svelte