Package and version
not applicable
What happened?
We noticed two things about the prisma (and @prisma/cli) package's npm publishing that look unintentional:
- dist-tags.latest points to a release candidate, not the latest stable release.
As of writing, npm view prisma dist-tags shows:
latest: 8.0.0-rc.15
prev: 7.10.0
next: 8.0.0-rc.10
latest is conventionally reserved for the most recent stable release — prereleases are normally published under their own tag (next, rc, etc.) precisely so that tooling and plain npm install prisma don't pick them up by default. Right now, anyone running npm install prisma without a version pin gets an 8.0.0 release candidate. @prisma/client, by contrast, correctly keeps latest on 7.10.0 with no rc line — so prisma and @prisma/client are currently inconsistent with each other on this point.
- The 8.0.0-rc.x releases report a different, seemingly stale repository field.
prisma@7.10.0's repository field is:
{ "url": "git+https://github.com/prisma/prisma.git", "directory": "packages/cli" }
which matches @prisma/client's repo (same monorepo, different subdirectory). But prisma@8.0.0-rc.10 and 8.0.0-rc.15 report:
{ "url": "https://github.com/prisma/prisma-cli.git", "directory": "packages/prisma" }
prisma-cli looks like an old, pre-consolidation repo name from before the CLI and client packages were unified into the current prisma/prisma monorepo. This looks like leftover or misconfigured metadata in the 8.x release pipeline rather than an intentional change.
Why this matters beyond cosmetics: several tools (we hit this with Renovate) use npm's repository metadata to detect when multiple packages come from the same monorepo and should be updated together. Because prisma's latest-tag metadata currently disagrees with @prisma/client's, that detection breaks specifically for prisma/@prisma/client — which is particularly risky here, since the CLI and client packages need to stay on matching versions.
Ask: could latest be pointed back at the current stable release (7.10.0 until 8.0.0 actually GAs), and could the repository field on the 8.0.0-rc.x releases be corrected to prisma/prisma / packages/cli, matching the stable line and @prisma/client?
Additional note Issue written in conjunction with claude code
What did you expect to happen?
A stable release should be installed if I run npm install prisma.
Minimal reproduction
npm install prisma
Environment
- Node: v24.16.0
- OS: Ubuntu 24.04
Additional context
No response
Package and version
not applicable
What happened?
We noticed two things about the prisma (and @prisma/cli) package's npm publishing that look unintentional:
As of writing, npm view prisma dist-tags shows:
latest: 8.0.0-rc.15
prev: 7.10.0
next: 8.0.0-rc.10
latest is conventionally reserved for the most recent stable release — prereleases are normally published under their own tag (next, rc, etc.) precisely so that tooling and plain npm install prisma don't pick them up by default. Right now, anyone running npm install prisma without a version pin gets an 8.0.0 release candidate. @prisma/client, by contrast, correctly keeps latest on 7.10.0 with no rc line — so prisma and @prisma/client are currently inconsistent with each other on this point.
prisma@7.10.0's repository field is:
{ "url": "git+https://github.com/prisma/prisma.git", "directory": "packages/cli" }
which matches @prisma/client's repo (same monorepo, different subdirectory). But prisma@8.0.0-rc.10 and 8.0.0-rc.15 report:
{ "url": "https://github.com/prisma/prisma-cli.git", "directory": "packages/prisma" }
prisma-cli looks like an old, pre-consolidation repo name from before the CLI and client packages were unified into the current prisma/prisma monorepo. This looks like leftover or misconfigured metadata in the 8.x release pipeline rather than an intentional change.
Why this matters beyond cosmetics: several tools (we hit this with Renovate) use npm's repository metadata to detect when multiple packages come from the same monorepo and should be updated together. Because prisma's latest-tag metadata currently disagrees with @prisma/client's, that detection breaks specifically for prisma/@prisma/client — which is particularly risky here, since the CLI and client packages need to stay on matching versions.
Ask: could latest be pointed back at the current stable release (7.10.0 until 8.0.0 actually GAs), and could the repository field on the 8.0.0-rc.x releases be corrected to prisma/prisma / packages/cli, matching the stable line and @prisma/client?
Additional note Issue written in conjunction with claude code
What did you expect to happen?
A stable release should be installed if I run npm install prisma.
Minimal reproduction
npm install prismaEnvironment
Additional context
No response