another extraction from #17805. I always felt bad about
`this.process([])`, and this PR replaces it with the steps that actually
occur — even though this is arguably duplicative, I find it much easier
to understand.
It also allows us to avoid activating batches with no queued effects,
thanks to the change in #17809. This saves us a bit of work in a
not-that-uncommon case.
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] 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
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
follow-up to #17808. This makes it a bit more explicit _why_ we do
certain things in `create_effect`, and gets rid of a redundant parameter
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] 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
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
This extracts part of #17805 into its own PR that can be merged
independently.
Today, if a (non-render) effect is created during traversal (e.g. an
`{#if condition}` block becomes true, and an `$effect` is created
somewhere inside it) then it goes through `schedule_effect`, ultimately
causing the loop in `flush_effects` to run again. This is wasteful. We
can instead push to an array — `collected_effects` — which is flushed
following the first traversal.
By using `collected_effects !== null` as a proxy for 'is traversing', we
can also simplify the bail-out logic inside `schedule_effect` and make
it work in more cases. Bailing out means that in the case that a signal
is written to during traversal (which is the case for `each` blocks, for
example), we can avoid triggering another turn of the loop because we
know that the affected effects are about to be discovered as a result of
the ongoing traversal.
All this brings us slightly closer to the intermediate goal in #17805 of
ensuring that scheduled effects always belong to a specific batch.
No test for this because it shouldn't have any user-observable impact,
though I've added a changeset out of an abundance of caution.
Another small tweak extracted from #17805, just to make that diff a bit
more legible.
By passing the `batch` to the branch commit callback, we don't need to
rely on the value of `current_batch` being the same as the batch
currently being processed. That gives us more control over the order of
operations — for example we can null out `current_batch` _before_
committing branches, which is important (at present, if a state change
occurs while those branches are being committed, it will belong to the
current batch, but the resulting effects will happen in the context of a
_new_ batch, which is something we need to avoid for the sake of
#17805).
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [ ] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## svelte@5.53.5
### Patch Changes
- fix: escape `innerText` and `textContent` bindings of
`contenteditable`
([`0df5abcae223058ceb95491470372065fb87951d`](0df5abcae2))
- fix: sanitize `transformError` values prior to embedding in HTML
comments
([`0298e979371bb583855c9810db79a70a551d22b9`](0298e97937))
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
We never cleared the list of (maybe)dirty_effects on the assumption that
once a batch has run them it's complete. But that's not the case when a
boundary has a pending snippet, in which case the pending snippet shows
up, so `blocking_pending` is already 0 and effects are flushed. That can
lead to effects being run unnecessarily, even leading to infinite loops.
So we clear them. This is safe because any additional effects would
either be scheduled by the boundary (which keeps track of the offscreen
effects created while the pending snippet is shown, and schedules them
once the pending snippet goes away) or by unskipping skipped branches
(which reschedules the effects inside it)
Fixes#17717
After creating the test I noticed it fails when run together with other
tests, but not alone, which lead me to discover that we're missing an
`unset_context`. I also added clearing of `#skipped_branches` just to be
safe.
Use separate scopes for function declarations/expressions and function
bodies. This prevents variable declarations from leaking into default
parameter initialization expressions.
Closes#17785.
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
The app shared between Kit and Svelte takes care of this now
### 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`
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## svelte@5.53.3
### Patch Changes
- fix: render `:catch` of `#await` block with correct key
([#17769](https://github.com/sveltejs/svelte/pull/17769))
- chore: pin aria-query@5.3.1
([#17772](https://github.com/sveltejs/svelte/pull/17772))
- fix: make string coercion consistent to `toString`
([#17774](https://github.com/sveltejs/svelte/pull/17774))
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Repository https://github.com/sveltejs/template is archived and no
longer maintained.
### 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`
---------
Co-authored-by: Rich Harris <hello@rich-harris.dev>
Closes#17758
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
The only change between 5.3.1 and 5.3.2 is
2106d5e872
to support versions of Node before 4, with the cost of a minuscule but
pointless performance hit. This is a pretty stable library, and there
have been no further changes in the ensuing year and a half, so it seems
pretty safe to pin to the previous version.
### 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] 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
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## svelte@5.53.2
### Patch Changes
- fix: update expressions on server deriveds
([#17767](https://github.com/sveltejs/svelte/pull/17767))
- fix: further obfuscate `node:crypto` import from overzealous static
analysis ([#17763](https://github.com/sveltejs/svelte/pull/17763))
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## svelte@5.53.1
### Patch Changes
- fix: handle shadowed function names correctly
([#17753](https://github.com/sveltejs/svelte/pull/17753))
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Fixes#17750 (though the change that causes the issue only surfaced this
more general bug)
We were not adding the correct scope to function ids. Instead it was
part of the function body/params scope, which leads to bugs when the
function name is shadowed within the function.
## Motivation
noticed that the documentation for the `<svelte:document>` still refers
to actions - probably would be better for beginners if it referred to
the newer attachments instead.
### 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] 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`
Alternative to #17188. I prefer this syntax, it's lighter and feels much
more natural to me. For me it's less about commenting things _out_ than
about just, well... commenting — I frequently want to do this sort of
thing:
```svelte
<button
// when the user clicks the button, the thing should happen
onclick={doTheThing}
>click me</button>
```
One difference between this and #17188 is that this doesn't add a node
to the AST, just like comments in CSS/JS. Haven't decided if that's
desirable or not. I think it's more correct (it's an AST, not a CST;
HTML comments are different insofar as they _can_ represent 'real'
nodes) but it might be less convenient when (for example)
pretty-printing.
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
This makes error boundaries run on the server if a new `onerror` handler
is passed to `render`. `onerror` can either synchronously or
asynchronously return a value. It should be a sanitized
JSON.stringify-able value so that it can be passed to the client for
hydration via a comment. `mount/hydrate` also get the `onerror`
property.
If no `onerror` is passed to `render` it will just throw just like
before, hence this is backwards compatible.
This work is important for SvelteKit to allow `+error.svelte` to make
use of them and in general to make boundaries properly work during SSR
(also see https://github.com/sveltejs/kit/issues/14398).
closes#15370
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Fixes#17726
The problem was that the head effect had no "keep me around"-flag, which
it needs because its children are not guaranteed to be present
immediately - as shown in the related issue, where the child effect is
only created once async work has completed.
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
Small tweak: except for `{#await ...}` blocks, which are a bit of an
anomaly, I'm pretty sure we _always_ want to deactivate the current
batch when unsetting context, otherwise it could incorrectly pick up
unrelated state changes. There might even be some subtle bugs lurking in
the system at present because we _don't_ always do this
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [ ] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## svelte@5.52.0
### Minor Changes
- feat: support TrustedHTML in `{@html}` expressions
([#17701](https://github.com/sveltejs/svelte/pull/17701))
### Patch Changes
- fix: repair dynamic component truthy/falsy hydration mismatches
([#17737](https://github.com/sveltejs/svelte/pull/17737))
- fix: re-run non-render-bound deriveds on the server
([#17674](https://github.com/sveltejs/svelte/pull/17674))
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
I tried to bring #14977 up-to-date but it's slipped too far. Also, I
wanted to try a slightly different approach.
In this PR, deriveds are memoized if they're created during render — in
other words if you have something like this...
```svelte
<script>
let thing = $derived(expensivelyComputeThing());
</script>
```
...`thing` will only be computed once. This seems correct since the
inputs should never change during render.
For deriveds created _outside_ render, we re-run the derived each time
it is accessed, which fixes#14954. This way, there's still _some_
overhead compared to how deriveds work in the browser (where they only
recompute when their dependencies have changed), but only in the rare
places where it is necessary.
There is one wrinkle: writable deriveds. On `main` these are just
regular old variables, which means they can be written to during render.
This PR currently preserves that behaviour, but I'm not sure it's
desirable. It prevents the values of non-render-bound deriveds from ever
updating, and makes no sense in the context of render-bound deriveds
since they shouldn't be changing during render _anyway_. So my
preference would be to disallow writes to deriveds on the server, but
I'm not sure if we would need to consider that a breaking change.
Draft because of that question, and also because I think we might be
able to tidy up some stuff around class fields.
- [x] figure out if we can delete some existing code around derived
class fields
- [x] figure out what to do about writable deriveds
- [x] add a test
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
Follow-up to #16271.
## Summary
- Allow `{@html}` blocks to accept `TrustedHTML` objects (from
TrustedTypes policies) without coercing them to strings
- This enables usage like `{@html myPolicy.createHTML(someHTML)}`
- Works in regular HTML, SVG, and MathML contexts
## Changes
- **`html.js`**: Instead of calling `create_fragment_from_html`, create
the wrapper element directly (`<template>`, `<svg>`, or `<math>`
depending on context) and assign the value to `innerHTML`. This
preserves `TrustedHTML` objects.
- **`reconciler.js`**: Removed the `trusted` parameter from
`create_fragment_from_html` since it's no longer used by `{@html}` and
all remaining callers want trusted HTML.
- **`template.js`** and **`snippet.js`**: Removed the second argument
from `create_fragment_from_html` calls.
## Notes
No tests added because JSDOM doesn't implement TrustedTypes.
Fixes#17735
Use the if/else hydration markers to know what "branch" (component or no
component) was rendered, and repair if differing.
### Before submitting the PR, please make sure you do the following
- [x] 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
- [x] Prefix your PR title with `feat:`, `fix:`, `chore:`, or `docs:`.
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.
- [x] If this PR changes code within `packages/svelte/src`, add a
changeset (`npx changeset`).
### Tests and linting
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint`
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## svelte@5.51.5
### Patch Changes
- fix: check to make sure `svelte:element` tags are valid during SSR
([`73098bb26c6f06e7fd1b0746d817d2c5ee90755f`](73098bb26c))
- fix: misc option escaping and backwards compatibility
([#17741](https://github.com/sveltejs/svelte/pull/17741))
- fix: strip event handlers during SSR
([`a0c7f289156e9fafaeaf5ca14af6c06fe9b9eae5`](a0c7f28915))
- fix: replace usage of `for in` with `for of Object.keys`
([`f89c7ddd7eebaa1ef3cc540400bec2c9140b330c`](f89c7ddd7e))
- fix: always escape option body in SSR
([`f7c80da18c215e3727c2a611b0b8744cc6e504c5`](f7c80da18c))
- chore: upgrade `devalue`
([#17739](https://github.com/sveltejs/svelte/pull/17739))
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
### 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`
Rich Harris
Elliott Johnson
github-actions[bot]
Paolo Ricciuti
Simon H
Maurício Kishi
Andre Hora
Ben McCann
Conduitry
Theodor Steiner