Repository navigation
Release RC packages (rc) - #4252
Open
github-actions[bot] wants to merge 1 commit into
Open
github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
github-actions
Bot
force-pushed
the
changeset-release/next
branch
6 times, most recently
from
October 25, 2026 05:01
67dafa0 to
cd4affe
Compare
github-actions
Bot
force-pushed
the
changeset-release/next
branch
from
October 25, 2026 05:03
cd4affe to
5d10339
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR was opened by the Changesets release 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 next, this PR will be updated.
nextis currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, runchangeset pre exitonnext.Releases
@solidjs/babel-plugin@2.0.0-rc.19
Patch Changes
<label {...props()} />) now defers behind a thunk like a spread beside other attributes, so it runs after the element's hydration key. A spread that created a memo shifted the element's key on the server only, and hydration missed the element ([2.0 rc.17] A lone spread runs before the element's hydration key on the server, after it on the client #4240).@solidjs/compiler@2.0.0-rc.19
Patch Changes
<label {...props()} />) now defers behind a thunk like a spread beside other attributes, so it runs after the element's hydration key. A spread that created a memo shifted the element's key on the server only, and hydration missed the element ([2.0 rc.17] A lone spread runs before the element's hydration key on the server, after it on the client #4240).<image>or<g>under control flow, in a fragment, or as a component root) inside their<svg>/<math>owner, as DOM templates already are, so valid SVG partials no longer fail thevalidatecheck.@solidjs/diagnostics@2.0.0-rc.19
Patch Changes
@solidjs/element@2.0.0-rc.19
Patch Changes
@solidjs/h@2.0.0-rc.19
Patch Changes
@solidjs/html@2.0.0-rc.19
Patch Changes
placeholder="Search…"rendered the literal…, anhrefwith&kept it in the URL, and components received static props like"a & b"undecoded. Values are now decoded once with the HTML parser's quoted-attribute rules, as text children already were.@solidjs/signals@2.0.0-rc.19
Patch Changes
2a0da2f: fix(web): refuse an async memo that resolves to an element ([2.0.0-rc.18] renderToStream: one value seroval cannot serialize leaves every value in its hydration batch unresolved #4242)
On the server, an async memo (or async iterable source) whose value is rendered output — JSX, a component's result, a
<Loading>/<Errored>boundary — can no longer reach the hydration serializer. A boundary's output failed in seroval, so its record never resolved and the hydrating client waited on the memo forever (streamed, the boundary reverted to its fallback); a template object crossed as data, duplicating the markup, and streamed the client could not insert it (UNRECOGNIZED_INSERT_VALUE). The memo now rejects where its value lands, with the new diagnosticASYNC_MEMO_ELEMENT(recorded on the observe channel; the dev message says what to do instead, other tiers carry the code), and its boundary contains the error like any render error: the nearest<Errored>renders its fallback and the client hydrates it; with none, the<Loading>fragment rejects and the client renders the subtree. Return data from the async memo and render the JSX from it. Ordinary data is never refused (only plain objects in the SSR template shape, boundary outputs and fragment arrays holding them count as rendered output), and content that never hydrates (<NoHydration>) is untouched.Also, a fragment failing while a boundary registered under an undefined key (one created inside an async memo's continuation) is pending no longer fails the whole request in
renderToStream.0dd40b2: Release deferred flight bookkeeping when iterator setup or the initial pull throws, so pending verdicts clear and truth readers receive the current error.
2d9c9aa: Drain pending computations after disposal, releasing retired roots while idle.
4ea2f49:
UNSTABLE_MEMO_OUTPUTno longer reports the memomerge()creates for a function source, such as a compiled conditional component spread (<Child {...(on() ? { tone } : {})} />). No one can pass that memoequals, so the warning had no fix (UNSTABLE_MEMO_OUTPUTfires on the memomerge()creates for a function source (<C {...cond() ? { a } : {}} />); its advice (equals) cannot be applied to that memo #4256). In observe builds the memo is now namedmerge. Production output is unchanged.253561e: A memo whose first read rejected stays uninitialized when it is re-asked: an
isPendingpass andlatest()throw NotReady until a value lands instead of readingundefined([2.0] A memo whose first read rejected readsundefined(not NotReady) in a verdict pass while it is re-asked #4244).solid-js@2.0.0-rc.19
Patch Changes
2a0da2f: fix(web): refuse an async memo that resolves to an element ([2.0.0-rc.18] renderToStream: one value seroval cannot serialize leaves every value in its hydration batch unresolved #4242)
On the server, an async memo (or async iterable source) whose value is rendered output — JSX, a component's result, a
<Loading>/<Errored>boundary — can no longer reach the hydration serializer. A boundary's output failed in seroval, so its record never resolved and the hydrating client waited on the memo forever (streamed, the boundary reverted to its fallback); a template object crossed as data, duplicating the markup, and streamed the client could not insert it (UNRECOGNIZED_INSERT_VALUE). The memo now rejects where its value lands, with the new diagnosticASYNC_MEMO_ELEMENT(recorded on the observe channel; the dev message says what to do instead, other tiers carry the code), and its boundary contains the error like any render error: the nearest<Errored>renders its fallback and the client hydrates it; with none, the<Loading>fragment rejects and the client renders the subtree. Return data from the async memo and render the JSX from it. Ordinary data is never refused (only plain objects in the SSR template shape, boundary outputs and fragment arrays holding them count as rendered output), and content that never hydrates (<NoHydration>) is untouched.Also, a fragment failing while a boundary registered under an undefined key (one created inside an async memo's continuation) is pending no longer fails the whole request in
renderToStream.Updated dependencies [2a0da2f]
Updated dependencies [0dd40b2]
Updated dependencies [2d9c9aa]
Updated dependencies [4ea2f49]
Updated dependencies [253561e]
@solidjs/universal@2.0.0-rc.19
Patch Changes
@solidjs/web@2.0.0-rc.19
Patch Changes
2a0da2f: fix(web): refuse an async memo that resolves to an element ([2.0.0-rc.18] renderToStream: one value seroval cannot serialize leaves every value in its hydration batch unresolved #4242)
On the server, an async memo (or async iterable source) whose value is rendered output — JSX, a component's result, a
<Loading>/<Errored>boundary — can no longer reach the hydration serializer. A boundary's output failed in seroval, so its record never resolved and the hydrating client waited on the memo forever (streamed, the boundary reverted to its fallback); a template object crossed as data, duplicating the markup, and streamed the client could not insert it (UNRECOGNIZED_INSERT_VALUE). The memo now rejects where its value lands, with the new diagnosticASYNC_MEMO_ELEMENT(recorded on the observe channel; the dev message says what to do instead, other tiers carry the code), and its boundary contains the error like any render error: the nearest<Errored>renders its fallback and the client hydrates it; with none, the<Loading>fragment rejects and the client renders the subtree. Return data from the async memo and render the JSX from it. Ordinary data is never refused (only plain objects in the SSR template shape, boundary outputs and fragment arrays holding them count as rendered output), and content that never hydrates (<NoHydration>) is untouched.Also, a fragment failing while a boundary registered under an undefined key (one created inside an async memo's continuation) is pending no longer fails the whole request in
renderToStream.4eb570e: Avoid retaining the first value-bound select and its form through the shared option-insertion hook.
e8b0b15:
renderToStream: a value that fails to serialize no longer leaves the other pre-shell hydration values pending on the client ([2.0.0-rc.18] renderToStream: one value seroval cannot serialize leaves every value in its hydration batch unresolved #4242). Pending promises registered before the shell (async sources and Loading boundaries'<key>_frcompletion flags) were handed to seroval as one object write. Since seroval 1.7, a value that fails to serialize ends the write it belongs to, so one failure stopped every value in that write. An async memo that resolves to an element, such as a nested<Loading>, left both boundaries unresolved and hydration never finished. The stubs are still held until the shell and handed over at the same point, in the same order, but each is now its own keyed write, so a failure only affects its own key, as on rc.17.Updated dependencies [2a0da2f]
board-example@0.0.1-rc.4
Patch Changes
canvas-example@0.0.1-rc.0
Patch Changes
server-dbmon-example@0.0.1-rc.3
Patch Changes
todos-server-example@0.0.1-rc.7
Patch Changes
test-integration@2.0.0-rc.19
Patch Changes