* chore: add warning for derived self referencin
* update build
* address feedback
* address feedback
* build
* messages shouldn't end with a period
* simplify test
* regenerate
* newlines are free
* no need to export this, we can move it closer to where it's used
* fix double negative
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* simplify
* fix/simplify
* fix/simplify
* start getting a grip of this mess
* tidy up
* more
* more
* more
* tidy up
* make things a bit less weird
* tweak
* more
* more
* add once once
* consolidate event handling code
* some progress. man, this stuff is entangled
* more
* tidy up
* simplify
* simplify
* more
* fix
* fix test names
* fix a bug
* tidy up
* changeset
* simplify
* regenerate
* tidy up
* tidy up
* tidy up
* simplify
* the module declaration case is already accounted for, above
* simplify/document
* typo
* "hoistable" is a misnomer
* hoist non_hoistable, rename
* more typos
* tweak
* regenerate
* fix: add css hash to custom element rendered with `svelte:element`
* simplify
* skip arg where possible
* drive-by improvements — remove some unnecessary arguments where possible
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* feat: function called as tagged template literal is reactively called
Co-authored-by: Oscar Dominguez <dominguez.celada@gmail.com>
* chore: re-organize import of visitors
* simplify
---------
Co-authored-by: Oscar Dominguez <dominguez.celada@gmail.com>
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* start refactoring client transform visitor code
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* tweak
* painful
* more
* simplify
* more
* more
* more
* more
* more
* tidy up
* changeset
* fix: allow nested `<dt>`/`<dd>` elements if they are within a `<dl>` element
This introduces a resets array, which means descendants that are forbidden are allowed again, if an element within the resets array is encountered between the tag and the forbidden descendant
fixes#12676
* better name
* chore: perf tweaks for actions/styles/classes
- check if we really need to add/remove the class (calling `includes` first is cheaper than always setting/removing it)
- check if we really need to update a style (calling `getPropertyValue/setProperty` is expensive)
- check if we should call the action's update function (this is not only a perf tweak but also a correctness fix)
closes#12652
* changeset
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* start moving visitors into separate modules
* remove unused code
* more
* more
* tidy up
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* alphabetize
* more
* fix
* more
* more
* consolidate
* more
* more
* more
* more
* more
* more
* more
* tweak
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* jfc what are we doing here
* more
* bizarre
* more
* more
* more
* more
* more
* more
* tidy
* one down
* dont merge
* hmm
* DRY
* more
* more
* tidy up
* tidy up
* add changeset, as this should have its own release
* tidy up
* oh i should probably hit save
* feat: make `<svelte:component>` unnecessary in runes mode
In Svelte 4, writing `<Component />` meant that the component instance is static. If you made the variable `Component` a reactive state variable and updated the component value, the component would not be reinstantiated with the new value - you had to use `<svelte:component>` for that. One reason was that having a dynamic component was more overhead, which is no longer the case in Svelte 5. We can therefore reduce the potential API surface area (by maybe deprecating `<svelte:component>` in the future) by allowing Svelte to recognize when a component variable is potentially dynamic. It turned out that this was already mostly the case. This PR fixes one case where it wasn't, and fixes another where this was wrongfully applied in legacy mode.
* we already have this function
* add interactive demos
* changeset
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
language tools has to type its own shape for backwards compatibility, and it currently doesn't include the `$on` and `$set` methods, which means without widening the type as done here you would get a "this shape is not accepted" type error when passing it to `ComponentProps`
closes#12627
Closes#12643
Very weird behaviour from the draggable setter...if you set element.draggable="false" it will actually set draggable to true (the boolean).
* better code generation for slot props in SSR
* simplify
* remove getters mechanism from server compiler
* changeset
* no need to use getters in SSR mode
* fix comment
Dominic Gannaway
github-actions[bot]
Rich Harris
Paolo Ricciuti
Simon H