SolidStart 2.0: A Framework in Transition for Solid Apps

The Problem SolidStart Solves and Who It Serves

SolidStart is the official application framework for Solid, a reactive JavaScript UI library. Solid itself provides fine-grained reactivity and components, but it does not dictate how to structure a full application: routing, server-side rendering, data loading, and deployment are left open. SolidStart fills that gap by offering a cohesive framework that ties Solid to a server environment, similar to how Next.js serves React. The target audience is developers who have chosen Solid and want a batteries-included solution for building complete web apps, rather than assembling routing and SSR manually. The README does not list specific features, but the existence of a dedicated package, landing page, and test suite makes the scope clear. The 2.0 branch is aimed at early adopters who are willing to track a rapidly changing codebase.

Architecture: A pnpm Monorepo with Nested Workspaces

The repository is organized as a pnpm-based monorepo with nested workspaces. The core package lives in packages/start, which is published as @solidjs/start. There is also apps/landing-page for the official site, apps/tests for unit and end-to-end tests using Vitest and Playwright, and apps/fixtures, which are small test projects. This structure is typical for a framework that needs to test itself against real usage patterns. The nested workspaces mean that commands often target a specific package or app using pnpm filters, such as pnpm --filter @solidjs/start. The monorepo approach lets the team run integration tests that exercise the framework from the perspective of a user project. For an outsider, this layout signals that SolidStart is not just a library but a full development environment with its own build and test harness.

Local Setup: Corepack, pnpm, and the Build Pipeline

To work on SolidStart from source, the README gives a precise sequence. First, clone the repository and enable the correct pnpm version with corepack enable. Then install dependencies with pnpm dedupe, which both installs packages and cleans duplicate entries from the lockfile. After that, run pnpm run build:all to build all packages and the landing page. If something goes wrong, pnpm run clean:all removes node_modules and dist folders so you can start over. This setup assumes you have Node.js at the version specified in .nvmrc, and Git installed. The use of pnpm dedupe is a specific choice: it prevents lockfile conflicts that can arise in a large monorepo. For a user who only wants to use SolidStart, the README points to the package README and official docs, but for contributors, these commands are the entry point.

Testing Workflow: Fixtures, Playwright, and Vitest

The testing strategy is layered. Unit tests check build artifacts and live inside the packages, while end-to-end tests run in apps/tests. To run E2E tests, you first install the Chromium binary for Playwright with pnpm --filter tests exec playwright install chromium. Then you build the test app with pnpm --filter tests run build, and finally run unit tests with pnpm --filter tests run unit, which puts Vitest in watch mode. For CI, there is a unit:ci variant that runs once. E2E tests are run with pnpm --filter tests run e2e. For manual development, the README suggests using the fixture apps: pick a fixture name and run pnpm --filter fixture-basic dev, for example. This workflow shows that SolidStart is serious about regression testing, but it also means that testing your own changes requires understanding the monorepo's filtering syntax. The reliance on Playwright and Chromium adds a system dependency that you must install once.

The 2.0 Branch Is a Moving Target

The most important caveat is in the README's callout: this branch is for SolidStart 2.0.0-alpha, under heavy development. The current stable version is maintained on the 1.x branch. This is not a subtle warning; it is a direct statement that the code you see on main is not production-ready. The release history shows recent versions like 2.0.4, 2.0.3, and 2.0.2, all published within a few days of each other, which indicates rapid iteration and likely breaking changes between patches. For an engineering team evaluating adoption, this means that any application built on 2.0 today may need to be updated frequently just to stay on the latest patch. The alpha status also affects documentation: the README explicitly points to the official docs for building apps, but those docs may not yet cover all 2.0 features. If you need a stable framework, the 1.x branch is the safer choice, and the README confirms it is still maintained.

Alternatives: Compare with Solid's Manual Setup or Other Frameworks

The main alternative to SolidStart is to build a Solid app without a framework, using Solid's own router and a server adapter of your choice. Solid provides @solidjs/router for client-side routing, and you can pair it with a server like Express or a static site generator. The difference in approach is that SolidStart aims to integrate routing, server rendering, and data loading into one package, whereas a manual setup gives you full control over each piece. Another alternative is to use a different framework entirely, such as Next.js for React, but that means abandoning Solid's fine-grained reactivity. For teams already invested in Solid, the decision is between the convenience of SolidStart and the flexibility of hand-rolling the server layer. The trade-off is that SolidStart's 2.0 alpha is unstable, while a manual setup, though more work, relies on stable libraries that you can pin and trust.

Maintenance and Upgrade Cost

The maintenance cost of SolidStart 2.0 is high right now. The README's own instructions for contributors include cleaning and rebuilding the entire monorepo, which suggests that the build process is not trivial. For users, upgrading between 2.0 alpha releases may require changes to your application code, because the API is not frozen. The project is MIT licensed, which means you can use it freely, including in commercial products, but the license does not come with any warranty or support obligation. The repository has a clear contribution guide and a template repository, which indicates an active community, but that does not reduce the upgrade burden on your side. Before adopting 2.0, you should check the changelog for each release and compare the API changes against your code. The 1.x branch is the stable alternative, and you can stay on it while 2.0 matures. The last push date and the rapid release cadence suggest that the team is actively working, but that activity also means the ground is shifting under you.

Editorial conclusion

Adopt SolidStart 2.0 if you are a Solid contributor or an early adopter who needs the latest features and is comfortable with breaking changes. Do not use it for production apps yet, because the README explicitly labels it as under heavy development. Before you start, verify that the 2.0 API matches your use case, check the official docs at docs.solidjs.com/solid-start, and confirm that your Node.js version matches the .nvmrc. If you need stability, stay on the 1.x branch, which is still maintained. The 2.0 branch is a moving target, and your code will likely need updates as the API settles.

Official sources

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