feat: simplify props

[Rich-Harris]

WIP. Putting this up in an incomplete state for visibility, as I likely won't be able to work on it any more today.

This is the first step towards a simplification of prop handling that I've had in mind — disallowing fallback props on bindings. After that I'd like to get rid of all the cases where $$props can be a signal, since it complicates things internally and defeats fine-grained reactivity in some cases.

Once that's in place, I think we can deprecate the accessors option, which would simplify things further.

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]

⚠️ No Changeset found

Latest commit: 86f931d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[dummdidumm]

We can't get rid of $$props being a signal because that's necessary for components that have spread props applied to them - else we don't get notified of new props being added or existing ones being removed.

Also, this should only apply to runes mode IMO, else upgrading to Svelte 5 becomes significantly harder.

[Rich-Harris]

We can't get rid of $$props being a signal because that's necessary for components that have spread props applied to them

I think it's doable — the spread_props function just needs to return a proxy with a $$spread: source(0) (or similar) that increments when keys change.

else upgrading to Svelte 5 becomes significantly harder

Does it though? It would be good to quantify 'significantly' — is use of fallback props with bound values widespread?

[dummdidumm]

It's not so much about how widespread it is (it's not uncommon, but also not common), it's more about how easily one can upgrade to Svelte 5. If you have just one dependency with one component which uses that pattern, you're blocked until you can upgrade. It also doesn't play well into our "upgrades are seamless" story. We have enough "not widespread" breaking changes already, let's not add another one unless technically unavoidable.

[Rich-Harris]

closing in favour of #9799