SolidStart's monorepo: filtered builds, fixtures and three test suites

The root package.json is a control panel for three build targets

SolidStart's own repository is a pnpm monorepo with nested workspaces, and the file that explains how it fits together is the root package.json. It is private, named solid-start-monorepo, version 0.2.0, authored by Ryan Carniato, type module. Its scripts do not run the framework. They run the workspaces inside it:

  "scripts": {
    "build": "pnpm run packages:build",
    "build:all": "pnpm run packages:build && pnpm run lp:build",
    "packages:build": "pnpm --filter=./packages/* build",
    "lp:dev": "pnpm --filter landing-page dev",
    "clean:root": "pnpx rimraf ./node_modules ./.vinxi/ ./.output/",
    "release": "pnpm build && changeset publish"
  }

Read those six lines and the layout explains itself. Everything under packages/ is built by one filter, apps/landing-page is driven through its own dev, build and start scripts, and .vinxi/ plus .output/ are where build output lands, since clean:root deletes exactly those two directories next to node_modules. The published npm packages carry the framework version, with @solidjs/start 2.2.1 released on 2026-11-03 alongside 1.5.1 and 1.5.0, while this root manifest stays at 0.2.0 because it is never published.

Local setup is clone, corepack enable, pnpm dedupe, build:all

The documented path from a clean machine to a working checkout is four commands. Clone and enter the directory:

git clone https://github.com/solidjs/solid-start.git
cd solid-start

Let Corepack pin the pnpm version that package.json asks for:

corepack enable

Then install, which is where this project parts company with most:

pnpm dedupe

pnpm dedupe is not only an install here. The README states that it installs dependencies and cleans the lockfile of duplicates, which is what stops nested workspaces resolving the same library twice. After that, build every package plus the landing page:

pnpm run build:all

When something is wrong, a missing node_modules being the case the README names, the documented recovery is one command before you repeat the install: `pnpm run clean:all`, which chains packages:clean and clean:root. Narrow the work when you can. The README suggests filters such as `pnpm --filter @solidjs/start ...` for targeting a specific package instead of rebuilding all of packages/.

The toolchain is pinned twice, in .nvmrc and package.json

Prerequisites are three items, and two of them are pinned somewhere in the repository rather than left to taste. Node.js should be the version written in .nvmrc at the root, with fnm named as the recommended manager so several Node versions can coexist on one machine. pnpm is installed globally with npm install -g pnpm, or handed to Corepack during setup. Git is needed to clone and manage the repository. A .npmrc sits at the root next to .nvmrc, so package manager behaviour travels with the checkout instead of living in your home directory, which is what keeps a laptop and a CI agent behaving the same way.

The root devDependencies that ship with it are a short list: @changesets/cli for the release flow, oxfmt for formatting, citty, tinyglobby, tippy.js and typescript at ^7.0.2. Vitest and Playwright are not root concerns by design, they belong to apps/tests, which is where the README puts the end-to-end suite. One gap is worth naming: nothing in the root scripts scaffolds an application. For creating a new template the README sends you to the separate solidjs/templates repository, so this manifest is a development workspace, not a project generator.

Unit tests that check build artifacts need the test app built first

The test sequence has an order that fails in a confusing way when you skip it. Chromium for Playwright is a one time install:

pnpm --filter tests exec playwright install chromium

Unit tests that assert on build artifacts need the test app built first:

pnpm --filter tests run build

Then the runner itself, which watches by default:

pnpm --filter tests run unit

The same workspace exposes `pnpm --filter tests run unit:ci` for a single pass, `pnpm --filter tests run unit:ui` for the UI, and `pnpm --filter tests run e2e` with `pnpm --filter tests run e2e:ui` for the browser suite. Artifacts land in a .tmp directory that `pnpm run clean:test` removes. Two details bite in automation: the default unit mode watches, so a pipeline that forgets unit:ci never terminates, and the Chromium download is a separate step, so a cold agent fails before any assertion runs. The root manifest has three scripts for the Vite ecosystem job: vite-ecosystem-ci:before-test installs Chromium, vite-ecosystem-ci:build runs build:all and builds fixture-basic, and vite-ecosystem-ci:test runs test:all in the tests workspace.

Fixtures are the manual test path, one name picks the app

For anything that needs a person watching a screen, the repository ships fixture apps instead of another assertion. The instruction is to pick the name of the fixture and run its dev script with workspace filtering:

pnpm --filter fixture-basic dev

apps/fixtures holds those apps, sitting next to apps/tests for the automated suites and apps/landing-page for the public site. The landing page also has a named entry point from the root, `pnpm run lp:dev`, and its own clean script, which shows how the monorepo is divided: each target is reachable both by filtering to its directory and through a root script with a short name. After editing a package the rebuild is `pnpm run packages:build`, and `pnpm run build:all` is the full sweep. Three clean commands cover the three layers, packages:clean for node_modules and dist inside packages/, lp:clean for the landing page, clean:root for root level caches. A .stackblitzrc at the root means the same repository can also be opened as a StackBlitz project.

Publishing rewrites each package's exports from publishConfig

Releases run through changesets rather than a hand edited version number. .changeset/ holds the pending entries, @changesets/cli provides the tooling at the root, and the release script is `pnpm build && changeset publish`, so a publish always builds first. A separate bump script runs node scripts/bump.js. The script that is easy to miss is rewrite-exports: it walks every directory under packages/ and copies .publishConfig.exports over .exports in each package.json, with jq doing the edit. The release script does not call it, so the manifest does not show when it runs. Formatting is handled by oxfmt through a format script and a format:check script, with .oxfmtrc.json holding its configuration at the root.

The main branch banner calls itself 2.0.0-alpha while 2.0.5 is published

The version picture needs reading in two parts. The README on the main branch carries an IMPORTANT notice saying this is the branch for the SolidStart 2.0.0-alpha under heavy development, and that current SolidStart is maintained at 1.x. The published packages tell a later story: @solidjs/start 1.5.0 on 2026-11-01, then 1.5.1 and 2.2.1 on 2026-11-03, with the last push to main on 2026-10-31. The alpha notice is therefore not a description of what npm users install, and stopping at that banner gives you the wrong idea of maturity. There are two lines to track: the 1.x branch is the one the README points at as current, and the 2.x line is the one published as 2.2.1.

One limit belongs here too. This README is a development and contribution document. It points application builders at packages/start/README.md and the official docs at docs.solidjs.com/solid-start, and sends template work to solidjs/templates. No router API, no server function signature and no deployment target appears anywhere in it, so it cannot answer a question about running an application, which is exactly what most visitors arrive wanting.

Editorial conclusion

Adopt SolidStart if you build on Solid and are willing to read docs.solidjs.com rather than the repository: the framework is real and the 2.x line shipped 2.2.1 on 2026-11-03. Hold off if you need application documentation in the repo or a scaffold command, since the root README sends template work to solidjs/templates. First check: whether you install the 1.x line the maintainers call current or a 2.x package still moving in patch releases.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes