Published 8.0.0-rc.1: top-level init says "Prisma Next", and the tarball ships the legacy dist/commands tree

[ankur-arch]

What happens

Two staleness issues in the published @prisma/cli@8.0.0-rc.1 (dist-tag next):

1. prisma-cli --help and prisma-cli init --help describe init as "Initialize a new Prisma Next project" / "Start the Prisma Next language server" (lsp). The product was renamed to Prisma 8 (Rebrand Prisma Next to Prisma 8 across docs, blog, and site web#8117); the RC a newcomer installs should not introduce a name the docs no longer use.
2. The npm tarball contains both the new dist/v8/ CLI (which the prisma-cli bin points at) and the older dist/commands/ tree including app/ and database/ command groups that no longer exist in the mounted CLI. Dead weight in the package and confusing for anyone inspecting it.

Also worth noting for the same release line: repo main mounts a top-level compute-config init wizard ("Write a committed compute config for this app"), but rc.1's published init is the ORM initializer — so there is currently no CLI way to scaffold prisma.compute.json, which the Deploy Button and connected repositories require. If the compute init wizard ships in the next RC this resolves itself; flagging so the docs plan can rely on a date.

Repro

npm pack @prisma/cli@8.0.0-rc.1
tar -tzf prisma-cli-8.0.0-rc.1.tgz | grep 'dist/commands' | head
npx -y @prisma/cli@8.0.0-rc.1 --help | grep -i next

Why it matters

The one-click deploy / Deploy Button journey sends newcomers to npx @prisma/cli@next; the first help text they see should match the Prisma 8 naming and command set the docs teach.

Reported during Prisma 8 end-to-end testing on behalf of Ankur Datta.

🤖 Generated with Claude Code

[ankur-arch]

Update from a fresh-context end-to-end run later the same day: 8.0.0-rc.2 is now on the next tag, and it changes part of this issue:

• ✅ rc.2's top-level init IS the compute-config wizard ("Write a committed compute config for this app"), and init --config-format json writes exactly the prisma.compute.json shape the Deploy Button docs show. The third bullet above (no CLI way to scaffold the config) is resolved.
• ❌ New blocker: init's printed next steps are wrong. After a successful init, the CLI's next-step hints tell the user to run npx -y @prisma/cli@latest app deploy and npx -y @prisma/cli@latest project link. That is doubly broken: latest resolves to 3.0.0-beta.30, and app is not a command even in rc.2 (CLI.UNKNOWN_COMMAND: No command registered for \app`, did you mean `lsp`?`). A newcomer who follows the printed hint lands in the abandoned CLI line.
• Still present in rc.2: "Prisma Next" naming (lsp help), and the help footer's docs link (prisma.io/docs/orm/tools/prisma-cli) 308-redirects to the ORM CLI reference — the wrong docs for someone deploying Compute apps.
• Cosmetic: every cold npx/bunx run prints a wall of peer-dependency warnings (@distilled.cloud/cloudflare, alchemy@2.0.0-beta.67) — a rough first contact.

Reported during Prisma 8 end-to-end testing on behalf of Ankur Datta.

[ankur-arch]

Important correction to this issue and my previous comment: @prisma/cli@latest (3.0.0-beta.30) is the current 3.x platform-CLI beta — actively published, with working app/database/build groups and its own compute-config init — not an abandoned 2021 line. I mis-read the version history; apologies for the noise.

Reframed, the still-valid findings are transition-consistency issues rather than breakage:

1. rc.2's init next-step hints send users back to the 3.x line (npx -y @prisma/cli@latest app deploy, … project link). Those commands work today, but someone who just adopted the Prisma 8 CLI gets bounced to the pre-8 command set — and the hints break the moment latest flips to 8.x. They should emit the rc's own commands (@next, git connect / composer deploy).
2. "Prisma Next" naming in lsp help, and the help-footer docs link resolving to the ORM CLI reference — unchanged.
3. The tarball shipping both dist/v8/ and the 3.x-era dist/commands/ tree — unchanged, though now clearly explained as the two lines cohabiting one package.
4. Peer-dependency warning spam on cold runs — unchanged.

Reported during Prisma 8 end-to-end testing on behalf of Ankur Datta.