Disallow props that look like directives

[benmccann]

Describe the problem

Currently every directive we add is technically a breaking change, because someone could have already (for some reason) been using a prop/attribute called bubble:foo or whatever.

Describe the proposed solution

Pick a format for directives (probably what we already have now) and make it a compile-time error to have a prop that looks like a directive but doesn't match the names of any of them.

Alternatives considered

No

Importance

nice to have

[Conduitry]

This should also apply to attributes that look like directives. I don't know how to make this play nicely with https://kit.svelte.dev/docs#anchor-options - I don't want SvelteKit-specific escape hatches in Svelte. We'll need to cross that bridge at some point.

[kevmodrome]

This should also apply to attributes that look like directives. I don't know how to make this play nicely with https://kit.svelte.dev/docs#anchor-options - I don't want SvelteKit-specific escape hatches in Svelte. We'll need to cross that bridge at some point.

Maybe a pre-processor in SK to get around this?

[TheCymaera]

How about a special syntax like this?

<div @on:click={...}></div>

This would be a big breaking change.

[rayl0]

How about a special syntax like this?

<div @on:click={...}></div>

This would be a big breaking change.

I think this should be done, instead of other one suggest above

[rayl0]

I don't know if they work the way they work but I use tailwindcss for almost all the css side of things.
So, it would be impossible for me to use class directives with tailwindcss
<div class="bg-white px-20 py-20" class:dark:bg-gray-400={toggleTheme} class:hover:hidden={isHidden}></div>

[dummdidumm]

I don't know if they work the way they work but I use tailwindcss for almost all the css side of things. So, it would be impossible for me to use class directives with tailwindcss <div class="bg-white px-20 py-20" class:dark:bg-gray-400={toggleTheme} class:hover:hidden={isHidden}></div>

IMO this should be ok, since the attribute name as seen by Svelte is class:.. and class: is a reserved keyword for Svelte, so it knows to interpret things afterwards as the class name.

This should also apply to attributes that look like directives. I don't know how to make this play nicely with https://kit.svelte.dev/docs#anchor-options - I don't want SvelteKit-specific escape hatches in Svelte. We'll need to cross that bridge at some point.

Thankfully we made the decision to have data-sveltekit-X for this, so we should be fine. There's the deprecated Sapper, but it likely only works with Svelte 3 anyway, so we shouldn't worry about that.

I propose to make this a warning in Svelte 4 and an error in Svelte 5.

[Conduitry]

I propose to make this a warning in Svelte 4 and an error in Svelte 5.

Would it being a warning be enough for us to feel safe adding new directives in some 4.x after 4.0? Or do you think we shouldn't worry about strict semver compliance here, because we're already non-compliant in 3.x and emitting warnings is a step in the right direction?

[dummdidumm]

I'd say so, yes. Also I think it's unlikely we add new directives in 4.x, it's more likely in 5.x

[benmccann]

There's a warning for these in v4

[farfromrefug]

@benmccann is there a way to disable that specific warning? In svelte-native we use prop: and ios: and android:. Maybe there is a way to say those are ok?

[dummdidumm]

Could you open a new issue so we can track this more visibly?