Svelte 5: unable to name a variable with the "same name" as a rune

[WarningImHack3r]

Describe the bug

When naming a variable with the same name as a rune, without the $, like state or derived or others, the compiler considers them as the same, thus leading to errors like Cannot access 'state' before initialization or errors relating to rune re-affectation.

Even if it's not a bug, runes re-affectation should be prohibited.

Reproduction

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAACj2N0QqDMAxFfyUEH9wQHHsaVQf7jrkH10ZWqG1pU2GI_z46N99yT3JPFhy1oYjivqAdJkKBN--xQn77HOJMhgkrjC4FmUm7IeE8a2cjhGQpQn3tbW_bKIP2nGc2xCBdsgwdFJEHpvJ0aPJGOhsZvgg6uGS2U0VBz6Sggx5fZIzrsfnblEtPkyvF76rc_Ec4Z3Fb79-xwskpPWpSKDgkWh_rB8K78zLqAAAA

Logs

No response

System Info

REPL, Svelte 5 next 175

Severity

annoyance

[7nik]

It's not really about runes but stores — if you declare a variable state, then $state is considered a store value, and thus, the error is that you are trying to read a store before its declaration. So, in general, the error is correct, though it can be misleading.

[WarningImHack3r]

@7nik yes indeed, makes sense! I'm quite new to using runes, so I kind of forgot about stores as I was focused on playing around with runes, but yeah, that makes sense.

In my opinion, there are two possible solutions here:

• Allow naming variables with the same name as runes, but prohibit creating stores with those names (seems quite hard with JS versatility)
• Completely disallow variable creation with those names

[MotionlessTrain]

Both are not easily feasible:

• when you have code like let state = getSomeResultFromSomewhereElse(), it is not feasible for svelte to detect what type(s) that could be. That would make this a runtime warning, which is not ideal at all
• Forbidding variables with the same names as runes would make adding new runes a breaking change (as more variable names are forbidden, which could break code).

Afaik because of those reasons, runes with the same names as variables are automatically disabled

[7nik]

The first solution is impossible. Static analysis cannot cover all possible cases.
IIRC, variables shadowing runes is intention behaviour - this allows the introduction of new runes without breaking existing code. But a warning should probably be emitted in this case.
BTW, due to this, your REPL is considered to be in legacy mode.

[WarningImHack3r]

BTW, due to this, your REPL is considered to be in legacy mode.

What does that mean?

• Forbidding variables with the same names as runes would make adding new runes a breaking change (as more variable names are forbidden, which could break code).

That's true... What's the best way around it then? A simply better warning message?

[7nik]

BTW, due to this, your REPL is considered to be in legacy mode.

What does that mean?

Svelte 4 / non-rune mode.
The mode can be switched with <svelte:options runes /> or runes: true in the compiler options.

[WarningImHack3r]

Svelte 4 / non-rune mode.

Weird, it was in Svelte 5 when I posted it. Fixed.

[trueadm]

There is already a warning for this problem, as you can see in the REPL.

[WarningImHack3r]

The current warning implies overriding runes is allowed, not that such a thing is not possible and the variable should be renamed

[trueadm]

The current warning implies overriding runes is allowed, not that such a thing is not possible and the variable should be renamed

I didn't interpret the warning to imply that you could override runes, more that the naming of your variable conflicts with a rune in scope, so rather than acting like a rune, it will act like a store. So renaming the variable avoids it from acting like a store.