Extract the Qwik CLI into @qwik.dev/cli and introduce qwik upgrade

[thejackshelton]

What is it about?

Move the Qwik CLI into a dedicated package, ideally its own repo, and unify upgrade tooling across the Qwik ecosystem.

What's the motivation for this proposal?

Problems you are trying to solve:

---

• @qwik.dev/core currently owns CLI code that is developer tooling, not runtime functionality.
• The CLI is pinned to core’s versioning and release flow even though it has very different goals and dependencies.
• CLI changes should go through CLI-focused CI flows, but today they are tied to the main framework repo and its runtime-oriented pipelines.
• The CLI wants codemod/parser/prompt tooling, which is a different toolchain than the runtime and build system.
• We are splitting effort between Qwik core CLI work and Qwik Astro, even though they are solving very similar problems.
• A lot of strong work has already gone into the Qwik Astro CLI, with great maintenance from @siguici for the past 2 years, and it would be great to merge efforts instead of duplicating them.

Goals you are trying to achieve:

---

• Give the CLI its own package, dependency graph, and release cadence (not pinned to monorepo).
• Rename migrate-v2 to the more durable command qwik upgrade for long term usage.
• Let CLI changes run through CLI-specific CI runners and test matrices.
• Clean up @qwik.dev/core by removing CLI-only concerns and dependencies.
• Create a shared CLI direction for Qwik, Qwik Astro, Void, and future meta frameworks.
• Make it easier to adopt CLI-native tooling such as codemod libraries, parsers, prompt UIs, and package-manager workflows. (e.g a lot of the tooling we use in Qwik + Astro including some novel packages from @siguici )

Any other context or information you want to share:

I think there is also a strong case for putting the CLI in its own repo instead of just its own package:

• It does not need to be pinned to the same versioning strategy as the runtime packages.
• It makes more sense for CI runners and release flows to be owned by the CLI itself.
• It uses CLI/tooling-oriented dependencies more than runtime-oriented ones.
• It would make @qwik.dev/core meaningfully cleaner.

---

Proposed Solution / Feature

What do you propose?

Create a new @qwik.dev/cli package to own the qwik command and move the current CLI code out of @qwik.dev/core.

The first goal of this package would be to replace the current migrate-v2 flow with a new top-level command:

pnpm qwik upgrade

The new CLI package would own:

• upgrade and codemod flows
• add/new/scaffolding commands
• prompt/UI logic
• CLI-specific dependencies and tooling

migrate-v2 can remain as a compatibility alias for a transition period, but upgrade should become the primary command going forward.

pnpm qwik upgrade <--- if qwik is in scripts in package.json otherwise the below
pnpm dlx @qwik.dev/cli upgrade
npx @qwik.dev/cli upgrade

Links / References

https://github.com/QwikDev/astro/tree/build/v2/libs/create-qwikdev-astro

[siguici]

This is an excellent idea 👌 I had actually thought about this before and drew a lot of inspiration from the Qwik CLI. It’s similar to what Astro does with their CLI kit, where a separate kit is used in create-astro and potentially elsewhere.

From what I understand, your proposal is to have a single CLI that lets users create a Qwik project with Qwik City, Astro, or other options.

I’d suggest keeping @qwik.dev/create-astro, but integrating it into create-qwik so it can prompt whether the user wants Astro, Qwik City, or something else — similar to how it currently handles choosing between a simple or full scaffold.

We could also provide a shared CLI kit like Astro’s to avoid duplicating code across org repos. This keeps the Astro creation command intact while giving full visibility in the main Qwik CLI.

Another idea: a separate repo for starter kits could be useful.

[wmertens]

Generally I don't like moving tightly coupled packages in their own repos, but for the CLI it's useful because the CLI should not be coupled to the qwik versions.

So I'm all for it. We'd still have the e2e-cli tests in the qwik repo but that's just for making sure that the CLI can install it, not the CLI itself.

Also, we should move the starters into a separate package. In latest v2 they are completely separate from the e2e tests now so it should be easy, and it would make the core package at least 1MB lighter. They would have to be versioned separately though for it to be useful.

Another option is to not package the starters at all, and instead rely on fetching them from e.g. github, but that would mean no offline use, or creating and updating a local cache.

[siguici]

That makes sense, and I think it leads us toward a cleaner separation of concerns.

Each starter could be tested independently, which would justify having a dedicated repo. That way, we ensure every template works on its own (install, dev, build), without relying on the CLI layer.

On the CLI side, we can focus on testing prompts, flows, and making sure the correct starter and dependencies are installed based on user input. This would also make it easier to support and validate third-party starters (like we did with @qwik.dev/create-astro).

Having a dedicated CLI repo (or set of repos) for shared tooling (kit/utilities/helpers, create-qwik, @qwik.dev/create-astro, etc.) could also help keep things modular and easier to test in isolation.

Overall, this would avoid polluting the main Qwik repo and help keep responsibilities clearly separated as the project grows.