feat: add warning for non-updated bindable

[paoloricciuti]

Closes #17589

I wonder if this should actually be considered a breaking change...it's just a warning but what if someone CI depends on no warnings to pass?

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.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

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

[changeset-bot]

🦋 Changeset detected

Latest commit: 8dea7d1

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

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

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

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@17600

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-17600-svelte.vercel.app/

[Ocean-OS]

The code seems good to me, but I'm questioning whether the mutation part should be removed, since I have a feeling a decent amount of components indirectly (at least to the compiler) mutate bindable props, e.g.

<script>
  let { prop = $bindable() } = $props();
  function_that_mutates_prop(prop);
</script>

which would lead to a false positive.

[paoloricciuti]

Mmm unless we count "passed to a function" as updated and we don't warn in that case.

[Ocean-OS]

True, but that still would count something like

let foo = { prop };
mutate(foo);

as a non-mutated prop.
I'm not trying to be contradictory, I just feel that there are more potential edge cases here than we realize.

[paoloricciuti]

Yeah but i think it's fine in this case...you can always update the function to actually mutate and then the warning would not make sense so better not fire "it there is the possibility". I feel like not including mutation would be worse than this no?

[Rich-Harris]

I started out thinking 'screw the edge cases' but there's actually quite a lot of them. If the problem is 'LLMs are dumb' then it seems like telling them 'don't make props bindable unless they're reassigned' would be better.

Unless we choose the lesser of two weevils:

1. omit the warning, and allow LLMs to generate unnecessary $bindable() props`
2. emit the warning, and discourage the use of $bindable() in cases where props are mutated but in a way that's insufficiently obvious to the compiler

Part of me wonders if we should just give up our quixotic attempt to prevent components from mutating stuff they don't own (i.e. get rid of the ownership_invalid_mutation warning) and make $bindable() purely about reassignments instead.

[dummdidumm]

make $bindable() purely about reassignments instead.

that indeed could be the best / most pragmatic solution