Conversation
…ation API sharedConfig is @internal in Solid 2.0 and stripped from the published solid-js declarations, so the adapter's imports fail with TS2305. Use the public API instead: - isHydrating() for the hydrating-mount checks (useBaseQuery, cacheAggregate, devtools clientOnly) - getHydrationWriter() + isHydratable() for the provider's server cache stream (respects <NoHydration> as ctx.noHydrate did) - takeHydrationValue() for useQuery's streamed entry, replacing sharedConfig.has/load, the s/v stamp decoding and the manual _$HY.r delete Requires solid-js / @solidjs/web 2.0.0-rc.13; the dependency bump follows once it is published. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…undaries Snapshot hydration lets everything outside an incomplete streamed boundary hydrate and move on; only boundaries still streaming hydrate against the server snapshot. The test pinned the opposite: a resumed boundary's DOM held the server value until the whole stream closed. Renamed to "cache writes during the open stream commit immediately outside pending boundaries": setQueryData and a mid-stream refetch reach #header at once, the pending feed boundary stays on its fallback and later hydrates from the server payload without refetching. Requires the Solid core change that recomputes nodes outside pending streamed boundaries on client writes. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Outside every pending streamed boundary a cache write commits immediately; under a pending boundary it waits for that boundary to resume against the server snapshot. Comment only. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
solid-js, @solidjs/web, @solidjs/signals and @solidjs/babel-plugin move to ^2.0.0-rc.13 across the Solid packages, examples and the vite integration; the solid-js / @solidjs/web peer floor rises to >=2.0.0-rc.13, the first release with the public hydration API the adapter now imports. @solidjs/vite-plugin moves to ^3.0.0-next.46 so the compiler it loads is rc.13 as well: next.44 passes a `componentNames` option that @solidjs/compiler rc.13 rejects, and holding the compiler back at rc.9 would compile against a different runtime than the one installed. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
… onto the live-shell latch until upstream does; fail on install/type-check errors; refetch the fixture The rc.12 release stopped at the TanStack Solid Query gate: `sharedConfig` is `@internal` since rc.12, so the adapter's type-check fails with TS2305 (QueryClientProvider.tsx, cacheAggregate.ts, useBaseQuery.ts). The public hydration API replaces it; until the adapter migrates upstream, the gate applies that migration (tests/patches/tanstack-solid-query-public- hydration.diff) to the fetched fixture. Self-removing: the patch applies only while the fixture still imports `sharedConfig` from solid-js, fails the gate if it no longer covers every such import, and is skipped once upstream has none. The adapter's "cache writes during the open stream commit when hydration completes" test pins the latch behavior the previous commit fixes (a shell write waiting for the whole page to hydrate). While the fetched fixture still carries that test, the gate rewrites it to the new expectation (tests/patches/tanstack-solid-query-hydration-latch.diff: the write commits to the shell at once). Self-removing the same way: applied only while the old title is present, failing the gate if the title survives the patch, skipped once upstream renames or rewrites it (TanStack/query#11751). Delete both blocks and patch files after that. Two gate bugs fixed on the way: - gitly serves its cached tarball first for any ref but master/main, so the gate kept re-testing the first `solid-query-v6-pre` download; `download(..., { force: true })` fetches the branch head. - shelljs's `exec` has no per-call `fatal` (only the global config), so a failed `pnpm install` or `pnpm run compile` (the adapter's type-check) returned silently. Both now run through a spawn helper that fails the gate on a non-zero exit or a signal; `npm pack` checks its exit code. SKIP_SOLID_QUERY_GATE in scripts/release.mjs is unchanged. Co-authored-by: Claude via Cursor <noreply@cursor.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
View your CI Pipeline Execution ↗ for commit b98c0b8
☁️ Nx Cloud last updated this comment at |
What
Moves
@tanstack/solid-query(andsolid-query-devtools) off Solid's internalsharedConfigonto Solid 2.0's public hydration API, released insolid-js/@solidjs/web2.0.0-rc.13:Why
In the Solid 2.0 RC,
sharedConfigis@internaland stripped from the publishedsolid-jsdeclarations, so the adapter fails to type-check (TS2305 atQueryClientProvider.tsx,cacheAggregate.ts,useBaseQuery.ts). The runtime reads also depended on undocumented shapes:context.serialize,context.noHydrate, thes/vstamps on serialized promises, and deleting from_$HY.rby hand. The public API owns those details now.Core PR: solidjs/solid#3718
Changes by file
solid-query/src/QueryClientProvider.tsx(serializeCacheOnServer): the castsharedConfig.context→getHydrationWriter(). The!ctx.async || ctx.noHydrateguard →!writer.async || !isHydratable(), so<NoHydration>is still respected; library writes are not gated by Solid itself.ctx.serialize(key, v)→writer.write(key, v). It's still called synchronously in provider setup, so the owner is known, and cache-event writes reuse the captured writer.solid-query/src/useBaseQuery.ts:hydratedMountand the in-passNEVERguard:!isServer && sharedConfig.hydrating→isHydrating().sharedConfig.has/load+ stamp decoding +delete _$HY.r[key]→takeHydrationValue(key), matching onstatus.resolved→ settle with the value;rejected→ settle empty;pending→ settle on the promise's outcome; no entry on a hydrated mount → prime and attach, as before.dataStoredoc comment now describes snapshot hydration (see the test change below).solid-query/src/cacheAggregate.ts:hydratedMount→isHydrating().solid-query-devtools/src/clientOnly.tsx:sharedConfig.hydrating→isHydrating().solid-query/src/__tests__/hydration.test.tsx: one test updated (see below).package.jsons +pnpm-lock.yaml: Solid rc.13 (see Dependencies)..changeset/solid-query-public-hydration-api.md: patch for@tanstack/solid-query,@tanstack/solid-query-devtoolsand@tanstack/solid-query-persist-client, including the new peer floor.No
sharedConfigorsolid-js/internalimport remains in the Solid packages.Test change: open-stream cache writes
cache writes during the open stream commit when hydration completesis nowcache writes during the open stream commit immediately outside pending boundaries.The old test pinned behavior that contradicts the design of Solid's snapshot hydration. Snapshot hydration exists so that everything outside an incomplete boundary hydrates and moves on normally. Nested boundaries that are still streaming hydrate against the server snapshot, so they don't fail hydration. The test instead required a boundary that had already resumed (
#header) to keep showing the server value until the whole stream closed. That wait defeats the point of snapshot hydration. rc.13 makes nodes outside still-pending streamed boundaries recompute on client writes.With the feed boundary still streaming, the test now expects:
setQueryData(['header'], …)reaches the cache and#header's DOM immediately.invalidateQueriesrefetches at once and its result (header-client) commits as it lands.#feedstays on its fallback throughout. When its chunk arrives, it hydrates from the server payload (feed-server) without a refetch, and#headerkeeps its client state.There are no adapter runtime changes for this.
Dependencies
solid-js,@solidjs/web,@solidjs/signals,@solidjs/babel-plugin:^2.0.0-rc.9→^2.0.0-rc.13insolid-query,solid-query-devtools,solid-query-persist-client, the Solid examples andintegrations/solid-vite.solid-js(all three packages) and@solidjs/web(solid-query) go from>=2.0.0-rc.9 <3.0.0to>=2.0.0-rc.13 <3.0.0. rc.13 is the first release with the APIs the adapter now imports.@solidjs/webwas already a peer ofsolid-query, so no peer dependency is added.@solidjs/vite-plugin:^3.0.0-next.44→^3.0.0-next.46, so the compiler it loads is rc.13 as well. next.44 passes acomponentNamesoption that@solidjs/compilerrc.13 rejects. Holding the compiler at rc.9 would compile against a different runtime than the one installed, which is the mismatch fix(solid-query): follow Solid 2.0.0-rc.9 #11543 fixed.pnpm install, only the Solid packages above changed.@emnapi/*dropped out with the rc.9 compiler's wasm binary.Validation
Against the published rc.13 packages (a plain
pnpm install, no local links):@tanstack/solid-query: 366 passed / 1 skipped (the pre-existing skip), including the renamed hydration test. The vitest typecheck reports no errors.test:types(TS 5.8, 5.9, 6.0,tsc --build),test:eslint,test:buildandbuildpass.@tanstack/solid-query-devtools: 33 passed.test:types,test:eslint,test:buildandbuildpass.@tanstack/solid-query-persist-client: 7 passed.test:types,test:eslint,test:buildandbuildpass.test:sherifandtest:knippass.vite buildsucceeds forintegrations/solid-viteand thebasic,simple,offline,basic-graphql-requestanddefault-query-functionSolid examples.The migration was also run before release against local core builds of solidjs/solid#3718, with the same 366 / 1.
— Claude via Cursor, on behalf of @ryansolid