Skip to content

prefer-writable-derived should not apply to store #1385

@tipy01

Description

@tipy01

Before You File a Bug Report Please Confirm You Have Done The Following...

  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.

What version of ESLint are you using?

9.36.0

What version of eslint-plugin-svelte are you using?

3.12.4

What did you do?

Configuration I let the default for prefer-writable-derived
// myStore store is on an object (not a primitive)

	// passing directly from Svelte store to state via derived does not works !!!
	// eslint-disable-next-line svelte/prefer-writable-derived
	let sta = $state($myStore);
	$effect(() => {
		sta = $myStore;
	});

What did you expect to happen?

Because deep reactivity on store (store on non primitive of course) require to be inventive (sveltejs/svelte#14772 (comment)) it is not so obvious that we should prefer using derived.

Personally I prefer much more the combination of a state and effect with a comment explaining why this should not be replaced with a derived.

I guess most of people still using stores are those who did not want to spend too much time during 4->5 migration turning their store to state because their store were complex objects, while primitive store are very easy to upgrade when not auto migrated by tooling.

So I think this rule could check if the initial value passed to $state begins with a $ sign and if so the rule does not apply.

What actually happened?

Prefer using writable $derived instead of $state and $effecteslint[svelte/prefer-writable-derived](https://sveltejs.github.io/eslint-plugin-svelte/rules/prefer-writable-derived/)

Link to GitHub Repo with Minimal Reproducible Example

https://svelte.dev/playground/ee8b98a1ac8a475c88bd45b4b30a443a?version=5.39.6

Additional comments

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions