Qwik v2 lives on main, and the scaffold command still says @beta

Main is the v2 beta branch, and the packages are rc builds

The first thing the project tells you is that this branch is Qwik v2, currently in beta, and that v1 lives on a separate `v1` branch. The most recent published releases are @builder.io/[email protected], [email protected] and [email protected], all published on October 25, 2026, and the last push to main was on November 2, 2026.

What that means in practice is that the code you read here is the code the next release is cut from, not the code most installs receive. Anyone who follows the scaffold command on this page gets a beta-generated project, and a team that only wants v1 has to pin the other branch by hand. Treat main as a moving target: read it to understand the design, decide separately whether to ship from it.

Four package managers, one command, and the tag is hardcoded

Project creation is offered through four package managers, and every variant carries the same @beta tag:

npm create qwik@beta
# or
pnpm create qwik@beta
# or
yarn create qwik@beta
# or
bun create qwik@beta

The choice of manager changes nothing about what you get, but the tag is not optional and there is no stable alternative documented on this page. If reproducibility of your starting point matters, record the resolved versions at the moment you scaffold.

Resumability means the client picks up mid-execution

The design claim is that a fully interactive site loads with almost no JavaScript and then picks up from where the server left off. Nothing on the page replays from the top: as the user interacts, only the necessary parts load on demand, which the project calls precision lazy-loading.

The cost sits on the other side of that trade. A page that starts with almost no JavaScript has not shipped the code for the things the user has not touched yet, so every interaction the visitor reaches becomes a fetch. A page with many interaction points spreads its code across many round trips rather than one bundle, and the work moves from a build step to the network at run time. The page you are reading does not describe a fallback for a client that cannot resume, nor any ceiling on how many separate pieces one view may pull in, so both limits are something you have to measure on your own routes.

Nightly builds come from URLs instead of version numbers

For anything tracking the main branch, the project hands out package URLs rather than versions:

https://pkg.pr.new/QwikDev/qwik/@qwik.dev/core@main
https://pkg.pr.new/QwikDev/qwik/@qwik.dev/router@main
https://pkg.pr.new/QwikDev/qwik/@qwik.dev/react@main
https://pkg.pr.new/QwikDev/qwik/@qwik.dev/devtools@main

These are pkg.pr.new addresses for each pull request and for the branches, and the instruction is to use them in place of a version when you want the latest build. Four packages are listed, all under the @qwik.dev scope. Everything else the repo ships has no nightly address here, including the create-qwik and eslint-plugin-qwik packages, so a dependency on main is available for the core, the router, the React bridge, and the devtools, and unaddressed for the rest.

Syncpack holds Vite 8 and Zod 4 in place, and explains the peers it cannot move

The workspace root is a pnpm monorepo named qwik-monorepo whose own version is workspace:*, and its dependency policy is enforced by syncpack version groups rather than left to each package. Vite is pinned to >=8 <9 for production and peer dependencies under the label Vite 8 only. The MCP SDK group pins zod to ^4.2.0 for @qwik.dev/mcp. The optimizer and ts-optimizer are pinned to workspace:* for every dependency type except local and dev, so a published build cannot pick up a mismatched optimizer.

Two peers are documented as immovable. eslint-plugin-import has no eslint 10 release yet, and the note says it already lints clean against it. @modular-forms/qwik asks for the v1 @builder.io peers while the documentation demo runs on v2. Those two exceptions live in pnpm.peerDependencyRules, which means an upstream release cannot resolve them by bumping a number.

Two devDependencies stay in the root package because e2e tests need them

The root package.json carries its own comments about why the dependency list looks the way it does, and they are worth reading before you clean anything up. Comment 01 states that devDependencies includes a reference to @qwik.dev/core: workspace:*, and that this is needed or the e2e tests fail, followed by comment 02 admitting it would be nicer to remove the dependency and fix the test. Comment 03 says devDependencies cannot include a reference to @qwik.dev/router, because the e2e test will fail.

The practical consequence is that the e2e suite, not the build, holds the shape of the root manifest. An apparently unused dev dependency in a monorepo root is usually the first thing a cleanup removes, and here removal is what breaks the tests, with the reason recorded only in comments rather than enforced by the manifest itself. Run the e2e suite before and after any root dependency edit, and read the comment on the line you are about to delete.

The Rust optimizer has three crates, one excluded and one untested

The optimizer is Rust, not TypeScript, and the Cargo workspace lists three members: packages/optimizer/napi, packages/optimizer/wasm, and packages/optimizer/core. The same file also puts packages/optimizer/wasm in exclude, so the WebAssembly crate is listed and excluded at once. Release builds are tuned for size with lto enabled, codegen-units set to 1, opt-level "z", and panic set to abort.

Test coverage is narrower than the member list. The Makefile target runs cargo test against packages/optimizer/core only, with the comment that there are no other tests and qwik-napi breaks the build, and the benchmark target is scoped to core the same way. So `make test` tells you nothing about the napi bindings that the JavaScript side actually loads. The publish-cli and install-cli targets also cd into src/optimizer/cli, a path that does not appear among the workspace members, which is worth checking before you rely on `make publish-cli`.

The container recipe and the dependency policy disagree about Node

The checked-in Dockerfile is short and old in one specific way. It starts from node:16.12.0-buster, installs Rust with rustup, puts the cargo bin directory on PATH, and then runs three commands:

RUN make install-rust-deps
RUN pnpm install
RUN pnpm build

Its Node version is fixed by that base image at 16.12.0, while the workspace pins Vite to >=8 <9 and the repository carries separate .node-version and .nvmrc files for the Node that contributors use locally. The Makefile step in the middle is what pulls in the Rust side: rustup update, the wasm32-unknown-unknown target, cargo-insta, and clippy. If you verify a change inside the image, check which Node and which toolchain you actually got before treating the result as representative.

Editorial conclusion

Qwik is worth a trial for a content or commerce site where first-load JavaScript is the metric you are judged on, and it is the wrong pick if you need a stable tag today, since main is v2 in beta and the starter is created with a @beta tag. Before you commit, read CONTRIBUTING.md for the source build, then check the two peers the workspace cannot bump (eslint-plugin-import and @modular-forms/qwik) and confirm that the Rust optimizer only has tests for its core crate.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. QwikDev/qwik on GitHub
4. README
5. Releases