Yuichiro Yamashita

For now, we can use [3.0.0-next.9](https://github.com/sveltejs/eslint-plugin-svelte/releases/tag/eslint-plugin-svelte%403.0.0-next.9). It will take some more time before v3.0.0 is released. Some breaking changes have already been introduced, but you/we should be able to address...

Please upgrade the plugin to [3.0.0-next.10](https://github.com/sveltejs/eslint-plugin-svelte/releases/tag/eslint-plugin-svelte%403.0.0-next.10) and disable `prefer-const` and enable `svelte/prefer-const`.

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...

`$derived` is also rune. Not signal. So I think we need to use `rune` instead of `signal` for the rule name.

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...

Close in favor of https://github.com/sveltejs/eslint-plugin-svelte/pull/933

@ota-meshi Reading the `typescript-eslint` source code, it appears that the following line always reports `SvelteRenderTag`. Since this issue cannot be resolved with parser tweaks, I believe the only option is...

I think we need to generate virtual code in order to obtain correct type and scope information via the `typescript-eslint` parser, and need to acquire type and scope information across...

This is fixed in Svelte5.

Certainly, this should be prevented, but it seems difficult to implement as an official ESLint rule. Simple patterns, such as ` { value = ev.target.value } />`, can be checked;...