[brenelz]

Bumps the Solid 2.0 app and starter to solid-js, @solidjs/web and @solidjs/diagnostics 2.0.0-rc.21, @solidjs/router 2.0.0-next.44 and @solidjs/vite-plugin 3.0.0-next.56. starter-solid/first-party-dependencies.json is updated to match.

The vite plugin depends on @solidjs/compiler ^2.0.0-rc.19, so pnpm kept the rc.20 compiler and babel plugin after the bump. Both lockfiles now pin them to rc.21 explicitly.

The biggest change for the tracker is in next.56: start.nodeServer now precompresses the client build and serves the .br or .gz file the request accepts. app-solid used to serve its JS and CSS uncompressed, which is why its initial load was 115 KB.

Benchmarks

I ran each benchmark locally on an Apple M2, first on main and then on this branch, with the same commands CI uses (pnpm --filter @framework-tracker/stats-generator run:<benchmark> <package>). These are local numbers and the CI run on this PR will differ, but the changes below were larger than the run-to-run spread.

Benchmark	main	This PR	Change
Initial load, all resources	115,198 B	43,885 B	−62%
Initial load, scripts	110,466 B	40,250 B	−64%
Initial load, stylesheets	1,935 B	818 B	−58%
Initial load, document	2,797 B	2,817 B	+1%
SSR request throughput (median per run)	337, 350, 353 ops/s	385, 387, 385, 386, 388 ops/s	about +10%
SSR body size	218.3 KB	218.3 KB	none
SSR load, 200 connections	391 req/s	417 req/s	+7%
Interaction processing, CSR	2.47 ms	2.48 ms	none
Interaction processing, SSR	2.67 ms	2.60 ms	none
Starter cold build	1,891 ms	1,930 ms	+2%
Starter dev server start	2,078 ms	1,716 ms	−17% (noisy)
Starter install	13,384 ms	11,912 ms	−11% (noisy)

The throughput row alternated builds of main and this branch so that machine drift would show up. The rendered page itself is still sent uncompressed, so the SSR body size does not change. The total interaction latency on the CSR and SSR pages moved in opposite directions between runs, from presentation delay (frame timing), while processing time stayed flat.

Results

rc.21 is a newer release within a version the tracker already follows, so it replaces the rc.20 entry instead of adding a point to the history, as CONTRIBUTING.md describes for patch releases. results/solid/versions/2.0.0-rc.20.json is renamed to 2.0.0-rc.21.json, and the framework and package versions in it and in latest.json are updated. Measured values still reflect rc.20 until the Benchmarks workflow reruns on main and opens a stats update PR. releasedAt also keeps its rc.20 date, the same way #728 left it for its patch bumps.

Verification

• pnpm install --frozen-lockfile and pnpm build in packages/app-solid and packages/starter-solid
• pnpm vitest run in packages/starter-solid (2 tests pass)
• node src/validate-first-party-dependencies.ts in packages/stats-generator
• pnpm test in packages/stats-generator (80 tests pass) and packages/docs (11 tests pass)
• pnpm build:docs, after which the built /framework/solid/ page shows rc.21 and no rc.20

Checklist

• If updating UI/UX components ensure you have added screenshots or a gif or video of the changes to the PR description
• If this is a dependabot PR that bumps a metaframework version, ensure that all package versions in the package match the versions installed by the metaframework version being bumped
• If this is a dependabot PR that bumps a metaframework version in a starter-* package, ensure that the deps, and file content matches the output of the metaframeworks recommended starter/default project

🤖 Generated with Claude Code

[AlexanderKaran]

@brenelz I would probably classify this as a patch update, which we don't track as a separate patch version. There are some rules around doing a patch version; see https://github.com/e18e/framework-tracker/blob/main/CONTRIBUTING.md#versioning

For a newer patch within a major or minor version already tracked (for example, SolidStart 2.0.0 to 2.0.5), update the exact framework version in both the starter and app package.json files, regenerate both lockfiles, and update the starter's first-party-dependencies.json. Update frameworkVersion and the framework package version in both ci-stats.json files, then rename the existing stats/<old-version>.json files to the new patch version and update their version fields. Make the same changes to the current and versioned stats JSON files under packages/docs/src/content/devtime and runtime. Replace the old patch entry rather than adding another point to the major or minor history. Leave measured values and diagnostic messages unchanged; they still reflect the previous patch until the Benchmarks workflow reruns after the change reaches main and opens a stats update PR.