Skip to content

feat: track Solid 2.0 alongside SolidStart - #709

Draft
brenelz wants to merge 1 commit into
e18e:mainfrom
brenelz:feat/solid-2
Draft

brenelz wants to merge 1 commit into
e18e:mainfrom
brenelz:feat/solid-2

Conversation

@brenelz

@brenelz brenelz commented Oct 27, 2026

Copy link
Copy Markdown
Contributor

This adds Solid 2.0 (solid-js 2.0.0-rc.19) as its own framework entry next to SolidStart. CONTRIBUTING asks for an issue before adding a framework, so please treat this draft as the proposal: happy to move the discussion to an issue or close this if you'd rather not track an RC.

Why a separate entry

The tracked SolidStart (2.0.6) runs on solid-js 1.9, which is what latest installs today. Solid 2.0 does not use SolidStart. Its full-stack setup is @solidjs/vite-plugin plus filesystem-routing, which is what create-solid generates for its "Solid 2.0" project type. Replacing SolidStart would end its history, so this keeps both. The entry has focusedFramework: false while Solid 2.0 is a release candidate.

What changed

  • packages/starter-solid: create-solid 0.12.0 with project type "Solid 2.0", the default basic template, TypeScript, SSR enabled, and no devtools. Enabling SSR adds ssr: true to the plugin options, writes server.js, and points start at it. The Solid packages are pinned to exact versions afterwards, and first-party-dependencies.json lists the solidjs-owned packages (eslint-plugin-solid is from solidjs-community, so it is left out). The prompts were read from create-solid 0.12.0's source and applied to solidjs/templates at 0045e64, because the CLI couldn't run interactively here. Re-running pnpm create solid with those answers should give the same files; please flag it if not.
  • packages/app-solid: a port of app-solid-start with the same routes and data. It builds with the plugin's start.node server (dist/server/node.js) and sets serverFunctions: true so the 'use server' loaders stay on the server, as SolidStart does by default.
  • stats-generator: a serve/solid.ts script and an in-process handleRequest handler, plus entries in the four runtime benchmark lists and ssr-load.test.ts.
  • results and docs: the framework and package enums, a solid entry in frameworks.ts, a framework page, logo mappings, methodology sections, README links, and a dependabot group.
  • prepare-chart.ts: compareVersionLabels now sorts a prerelease before its release, as semver does. Plain localeCompare put 2.0.0 before 2.0.0-rc.19, which would mis-order Solid 2.0's history once 2.0.0 ships. This is the first prerelease version the tracker records.

results/solid/ is not included. It should come from the CI run, so the framework page and README links have no data until then.

Verification

  • pnpm format:check, pnpm lint, pnpm type-check, and pnpm build:docs pass, and /framework/solid/ renders.
  • node --test src/*.test.ts in stats-generator passes (76 of 76), and validate-first-party-dependencies.ts passes.
  • pnpm knip reports one duplicate export in packages/results/src/schemas.ts, which is already on main.
  • The starter benchmarks run locally through the tracked-file copy: build, dev server, install, framework dependencies, Node engines, browser baseline, and core-js.
  • The app benchmarks run locally: SSR request throughput, server-side rendered, client-side rendered, and verify-ssr-load.ts.

Known differences worth a look

On a local laptop run, Solid 2.0's dev time is much faster than SolidStart's, but it ships more client JavaScript (the Solid 2 runtime chunk is about 26 KB gzipped against 9.6 KB), and its HTTP SSR load test trails SolidStart on the link-heavy /server-side-rendered page. Most of that gap is per-link work in the router's server link state, which solidjs/solid-router#701 reduces. These are not Depot numbers, so CI's run is the one to compare.

Checklist

  • If updating UI/UX components ensure you have added screenshots or a gif or video of the changes to the PR description (no UI changes beyond a new framework page and logo mapping)
  • 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 (not applicable)
  • 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 (not applicable)

🤖 Generated with Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant