feat: allow modifiying derived props

[dummdidumm]

Started this when looking into #9998 and thinking $derived is necessary - turns out it's not, but I thought I'd create this PR anyway and put it up for discussion whether or not this should be allowed.

Pros:

• You can write code that's valid using it, so it may be overzealous to disallow it
• You can hide the $derived behind a getter and then the validation wouldn't catch it anyway
• We do allow it for the bind:x case

Cons:

• May allow spaghetti code

Personally I lean towards relaxing this rule.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 1794b0f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
svelte-5-preview	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 4, 2024 0:54am

[brunnerh]

I have also come across this with e.g. editing a selected object from a list via some key. E.g.

const items = $state([
	{ text: 'Item 1' },
	{ text: 'Item 2' },
	{ text: 'Item 3' },
]);
let index = $state(0);
const current = $derived(items[index]);

const onClearCurrent = () => {
	current.text = ''; // error
};

Would be in favor of allowing this.
Related:

• Svelte 5: Allow binding to properties of objects returned from functions? #9506

@Prinzhorn
In Svelte 5 reassigning a derived variable is a compiler error. So the only way to create an inconsistency would be to create a new object in $derived and modifying a property; if the returned object is an existing one, the $derived's logic should still hold.

But as dummdidumm pointed out, creating this inconsistency is already possible in various ways, including bindings and some indirection.

[Prinzhorn]

In Svelte 5 reassigning a derived variable is a compiler error

I assumed this PR was about removing this restriction. If it's only about mutating derived objects then ignore my comment above.