Repository navigation
All published 8.0.0-rc CLIs crash at startup: @prisma/cli-engine@0.1.1 lacks the readActiveAccessToken export #202
Description
Summary
Every published 8.0.0-rc build of the unified CLI (prisma@next = 8.0.0-rc.3/rc.4, @prisma/cli@next = 8.0.0-rc.3/rc.4) crashes at import time, before any command runs:
file:///.../node_modules/@prisma/cli/dist/cli.js:4
import { ..., readActiveAccessToken, ... } from "@prisma/cli-engine";
SyntaxError: The requested module '@prisma/cli-engine' does not provide an export named 'readActiveAccessToken'
Cause
@prisma/cli@8.0.0-rc.3andrc.4both pin@prisma/cli-engineto exactly0.1.1.- Published
@prisma/cli-engine@0.1.1(2026-08-17) does not exportreadActiveAccessToken(grep -c readActiveAccessToken node_modules/@prisma/cli-engine/dist/index.js→ 0). - Repo HEAD's
packages/cli-engine(also versioned 0.1.1) does export it (src/exports/index.ts,src/active-access-token.ts), so the CLI was published against an engine state that was never published.dist-tagsnow showdev: 0.2.0, but the rc CLIs' exact pin keeps resolving the broken 0.1.1.
Repro
npx -y @prisma/cli@next --version # SyntaxError above (Node 24.11.1, macOS)
npx -y prisma@next --version # same
npx -y @prisma/cli@8.0.0-rc.3 --version # sameImpact
- Every
npx @prisma/cli@next …/npx prisma@next …command in the docs fails today. - It cascades:
orm initscaffolds a project, installs@prisma/cli@nextas a devDependency, then shells out to it for the initialcontract emit— soorm initends withCLI.INIT_EMIT_FAILEDfor every new user (exit code 5).
Suggested fix
Publish a cli-engine version containing the new exports and republish the rc CLIs pinned to it (or add a publish-pipeline check that installs the packed CLI tarball and runs --version before tagging next — docs/oss/release-automation.md already records a similar miss for @prisma/composer-cli@0.6.0).
Found while validating the docs against 8.0.0-rc.4 (prisma/web#8151); the repo-built CLI works fine, published artifacts do not.
🤖 Filed with Claude Code on behalf of datta@prisma.io
Activity
ankur-arch commentedon Aug 18, 2026
Status as of today (2026-08-18):
npx -y prisma@next --version(resolves 8.0.0-rc.4) still fails withSyntaxError: The requested module '@prisma/cli-engine' does not provide an export named 'readActiveAccessToken'on Node 24.11.1/macOS. Bothprisma@8.0.0-rc.4and@prisma/cli@8.0.0-rc.4pin@prisma/cli-engine@0.1.1exactly.@prisma/cli-engine@0.2.0(with the missing exports) published today at 08:21 UTC, and chore(release): bump to 8.0.0-rc.5 #207 is the rc.5 release PR — but chore(release): bump to 8.0.0-rc.5 #207 as written would have re-shipped the crash:packages/prismastill pinnedworkspace:0.1.1, whichpnpm publishpublishes verbatim as0.1.1. The engine bump tooling only rewrotepackages/cli's pin, and no check compared a sibling's pin to the engine version actually shipping.bump-cli-engine-versionrewrite every consumer manifest, and adds the publish-pipeline guard this issue suggested: release-channel conformance now fails withengine-pin-mismatchwhen any packed sibling pins an engine version other than the one packed beside it.This issue closes when rc.5 (rebased on #210) is on
nextandnpx -y prisma@next --versionsucceeds.ankur-arch commentedon Aug 18, 2026
Independent verification of the fix on the published stack (fresh npx cache, macOS, Node 24.11.1):
npx -y prisma@next --version→{"ok":true,"result":{"version":"8.0.0-rc.5"},"exitCode":0}, with@prisma/cli-engine@0.2.0resolved — where rc.4 crashed at import. The pipeline guard side landed in #210: the engine bump now rewrites every consumer manifest, and release-channel conformance fails when any packed sibling pins an engine version other than the one packed beside it (that check caught the stalepackages/prismapin that would have re-shipped this crash in rc.5).