* breaking: disallow binding to component exports in runes mode
Svelte 4 allowed you to have `export const foo = ..` in component A and then do `<A bind:foo />`. This is confusing because it's not clear whether the binding is for a property or an export, and we have to sanitize rest props from the export bindings.
This PR therefore introduces a breaking change in runes mode: You cannot bind to these exports anymore. Instead use `<A bind:this={a} />` and then do `a.foo` - makes things easier to reason about.
* Update sites/svelte-5-preview/src/routes/docs/content/03-appendix/02-breaking-changes.md
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* tweak messages
* fix tests
* use component.name
* oops
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* fix: run event attributes after binding event listeners
By running the event listener logic inside an effect on the first run we guarantee that they're attached after binding listeners. Fixes#11138.
* give arrow functions stable id, better code gen
* optimise normal function expressions too (rare but valid!)
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* Revert "fix: take outroing elements out of the flow when animating siblings (#11208)"
This reverts commit c44234dc2f.
* fix: measure elements before taking siblings out of the flow
* lint
* add changeset back
* changeset
* fix: fall back to component namespace when not statically determinable
In #10006 we added more elaborate mechanisms to determine which namespace a given element is in. For `<svelte:element>` we added a "can't know at compile time" case and introduced a limited heuristic into the runtime.
This doesn't work for a few reasons:
- we're checking the parent's namespace to determine the current namespace, but the element itself could be the one that _changes_ the namespace
- as mentioned in the previous comment already, on the first render we can't do any parent analysis
- it does not take into account the static component namespace
The last point is the crucial one: In Svelte 4, we're falling back to the component namespace if we can't know statically - e.g. if someone added `<svelte:options namespace="svg">` then `<svelte:element>` should fall back to that namespace instead.
We were not doing that up until now, which introduced a regression. Fixing this also means getting rid of the (flawed) "can't know statically" heuristic.
Fixes#10858, though for a complete solution we likely need some way to tell `<svelte:element>` the namespace at runtime through a special attribute. Maybe we can use `xmlns` for that like we do in the static case
* support dynamic svelte:element namespace through xmlns attribute
* fix
* feat: allow $inspect reactivity map, set, date
* feat: inspect map without adding new data source
* feat: add inspect
* feat: define inspect on dev mode only
* fix: lint error
Ownership was not widened when assigning a sub state to a different top level state. The set of owners for the state was zero because the owner was on the original parent, but that one was reset to null because it's now the top level of a different state. That meant that there was no owner but also no parent to check for the owner, which is an invalid combination resulting in a nullpointer (and also potentially false positive warnings in other situations).
fixes#11204
* breaking: warn/error on old syntax in runes mode
- warn on slots and event handlers in runes mode
- error on `<slot>` + `{@render ...}` tag usage in same component
closes#9416
* render tag + slot could occur in legacy mode as well, error there, too
* rename metadata.o to metadata.owners, tweak check_ownership implementation
* track parent relationships
* update
* changeset
* adjust test to reflect new semantics
* prevent component using bind: with object it does not own
* failing test
* fix#11060
* add explanatory comment
* don't accidentally narrow global ownership, fix has_owner method
* widen ownership if assigning different state proxies to one another
* don't set owners to null when parent exists
* fix
* only recurse into POJOs
* handle cycles on context
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
Co-authored-by: Dominic Gannaway <dg@domgan.com>