* start reorganising messages
* tidy up
* more
* more
* more
* alphabetise
* consolidate
* more
* more
* more
* more
* more
* more
* alphabetise
* more
* this is no longer needed
* no longer necessary
* more
* more
* fix
* regenerate messages
* more
* more
* tighten up rune validation
* more
* fix
* more
* tweak a11y messages
* add server errors
* overhaul runtime errors
* regenerate messages
* unused
* lint
* more
* more
* Update packages/svelte/messages/compile-errors/script.md
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* Update packages/svelte/messages/client-warnings/warnings.md
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* fix
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* fix: mark `accessors` and `immutable` as deprecated
* add warnings for deprecated <svelte:options> attributes
* disable accessors in runes mode
* update tests
* tidy up
* the hell?
* regenerate types
* if I would get a dollar for every windows bug I fix I would be a millionaire by now
* return instance _and_ props in runes mode, move flushSync into shared code, don't set accessors in runes mode
* goddammit
* note breaking change
* fix
* regenerate messages
* Revert "return instance _and_ props in runes mode, move flushSync into shared code, don't set accessors in runes mode"
This reverts commit a47827e57d.
* pass instance to tests
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
This is a typings PR and the companion PR to sveltejs/language-tools#2336
It introduces two new types:
- Binding: Marks a property as being bound (i.e. you must do bind:x)
- Bindable: Marks a property as being able to be bound (i.e. you can do bind:x)
Language tools then uses this generate code accordingly which then generates type errors.
All the other type gymnastics are there to ensure that you don't interact with these bindable types when using mount or hydrate or ComponentProps<MyComponent>, i.e. these two types should be mostly opaque for day-to-day users.
For backwards-compatibility, all properties are automatically wrapped with Bindable, which means existing type definition files will continue to work from a types perspective. Language tools opts into strict bindability by providing its own constructor definition for all generated classes in runes mode which omits the "wrap everything with bindable" behavior.
* 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
Rich Harris
github-actions[bot]
Simon H
Craig Jennings
Yuichiro Yamashita
Vaibhav Rai
Jeremiasz Major
Caique Torres
Paolo Ricciuti
Tan Li Hau