Open bfanger opened 5 days ago
Latest commit: 642e4dd8a6cc23bcbb05d8af0205d5789d968b9a
The changes in this PR will be included in the next version bump.
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
Thank you for the PR!
This is just small point but return value of $effect.root
should use const
according to the docs, so I think rune-declaration-kind
or something like that is better rule name and we can check $effect.root
also.
const cleanup = $effect.root(() => {
$effect(() => {
console.log(count);
});
return () => {
console.log('effect root cleanup');
};
});
Thank you for the rule suggestion and opening this PR!
However, I think this rule will conflict with the prefer-const
rule in ESLint core as it is.
I think we need to consider how to avoid the conflict.
Could you please propose the rule in a new issue first?
@ota-meshi I was thinking about implementing a svelte/prefer-const
rule which would extend prefer-const
but ignore signals declarations.
@baseballyama $effect.root
is a rune, but not a signal, the svelte/prefer-const
rule should convert it to a const
$derived
is also rune. Not signal. So I think we need to use rune
instead of signal
for the rule name.
$derived
returns a signal: https://github.com/sveltejs/svelte/blob/8904e0f6cca7c423cd6232ba38870362cf840e63/packages/svelte/src/internal/client/reactivity/deriveds.js#L23
If the svelte compiler injects $.get()
when you're using a variable then it's a signal.
I know. But we don't use the word "signals" for Svelte developers. We use "runes" instead. We need to use word which mentioned in the docs as much as possible to reduce cognitive cost.
Svelte 5 allows using both
let
andconst
for signals, in regular JavaScriptconst
means:But signals do change and are reassigned by Svelte's reactivity system.
This ESLint rule converts:
into