`orm init` installs `prisma@next` (8.0.0-rc.10) while `latest` is rc.13, and rc.10 `migration plan` silently plans a full recreate without a `db` ref

Package and version

[email protected] (the latest tag); orm init installs [email protected] (the next tag)

What happened?

npx prisma@latest orm init runs npm add -D prisma@next @types/node and npm add -D @prisma/[email protected]. Today the dist-tags are:

package	next	latest
prisma	8.0.0-rc.10	8.0.0-rc.13
@prisma/cli-engine	0.2.3	0.3.0

So the CLI the user invoked (rc.13) scaffolds a project whose own npx prisma and npm run contract:emit run an older CLI (rc.10). @prisma/[email protected] peer-depends on @prisma/[email protected], so two cli-engine versions end up in the tree as well.

The version skew is not cosmetic. rc.10 has a migration-planning behaviour that rc.13 already fixed:

• With rc.10, prisma migration plan --name add-user-bio in a project that has applied migrations but no db ref exits 0 and writes a migration with "from": null and 6 operations for a one-column change. It silently planned a full recreate from an empty database. The following prisma db migrate then fails with MIGRATION.PATH_UNREACHABLE: Current contract has no planned migration path.
• With rc.13, the same command refuses with MIGRATION.PLAN_ORIGIN_UNKNOWN: Cannot determine the plan origin: migrations exist but no origin is named and lists the three ways out.

A user who follows the docs with npx prisma@latest but runs the scaffolded package scripts gets the rc.10 behaviour without knowing it.

What did you expect to happen?

orm init installs the same version of prisma that was invoked (or prisma@latest), and the @prisma/cli-engine version that matches the runtime's peer dependency. Alternatively, move the next dist-tag forward to rc.13 so both tags resolve to the same CLI.

Minimal reproduction

1. mkdir app && cd app && npm init -y
2. npx prisma@latest orm init --yes --target postgres --authoring psl
3. cat package.json shows "prisma": "^8.0.0-rc.10" and "@prisma/cli-engine": "0.2.3"; npx prisma --version inside the project reports rc.10 while npx prisma@latest --version reports rc.13.

To see the planning difference:

1. Set DATABASE_URL, run npx prisma contract emit, npx prisma migration plan --name init, npx prisma db migrate (plain, without --advance-ref db).
2. Add a field to the model, run npx prisma contract emit, then npx prisma migration plan --name add-field. rc.10 exits 0 with "from": null and a full-recreate plan; npx prisma@latest migration plan --name add-field (rc.13) refuses with MIGRATION.PLAN_ORIGIN_UNKNOWN.

Environment

• OS: macOS 15
• Node.js: v24.11.1
• Package managers: npm 11, pnpm 11.25.0 (same result)
• Database: PostgreSQL 17 (local)

Additional context

Seen in 12 of 15 guide validation runs on 2026-09-10 (Turborepo, pnpm workspaces, Bun workspaces, React Router, SolidStart, Cloudflare Workers, Docker, GitHub Actions, and the four "switch to Prisma" guides). The Turborepo run is where the full-recreate plan was observed. The guides work around it with npm add -D prisma@latest right after orm init.