prisma dev finds the alchemy executable in a plain pnpm project by wmadden-electric · Pull Request #332 · prisma/composer

wmadden-electric · 2026-10-01T06:44:01Z

Found while proving slice 3 of the one-config-file project from the prisma binary (prisma/orm#30536).

$ pnpm add -D prisma @prisma/composer @prisma/composer-prisma-cloud   # a plain pnpm project
$ pnpm prisma dev module.ts
DEPLOY.ALCHEMY_BIN_MISSING  could not find the alchemy executable in node_modules/.bin

The emulators were up; the deploy child never started. Adding alchemy as a direct dependency worked around it, which nothing tells a user to do.

The decision

Composer finds Alchemy where the app's own @prisma/composer finds it. The lookup resolves @prisma/composer/package.json from the app directory with Node's resolver, takes the alchemy package in the nearest node_modules above that package's real location, reads its bin entry, and runs that file with Node. The executable and the generated stack file's alchemy imports therefore come from the same install by construction, whatever version of @prisma/composer-cli is running. DEPLOY.ALCHEMY_BIN_MISSING stays for the case where the package cannot be resolved, and now says what to check.

Why it broke

pnpm links node_modules/.bin entries only for a project's direct dependencies, and alchemy is a dependency of @prisma/composer, not of the app. The repository never saw it because its .npmrc sets node-linker=hoisted, which links every bin. The old lookup also depended on a shell shim and a Windows .cmd variant; running the JS entry with Node directly needs neither.

The dev stack had the same bug one level down

With the executable fixed, the converge still failed: the generated dev stack file imported alchemy/State/LocalState itself, and the app's node_modules has no alchemy. Core now offers devState() on @prisma/composer/local-target, and the stack file imports that. Tests assert neither generated stack file imports from alchemy.

What a failed deploy prints to reproduce

The failure output and the generated file headers used to say alchemy deploy …, a command that does not exist in a plain project, the very case this fixes. The adapters now report the command line they actually spawned, and the failure output prints it, single-quoting arguments so a stage name containing $ or a quote cannot expand when pasted. ADR-0007's "run it by hand" promise is amended to describe that printed command.

Which runtime Alchemy runs under

Composer starts Alchemy's launcher with Node: the host's own Node when the host is Node, the first node on PATH when the host is Bun, failing with DEPLOY.NODE_MISSING if there is none. Alchemy's own launcher may still switch itself to Bun when it detects bunx or bun run through the package-manager environment. The guide gives the measured table:

Form	`prisma` runs under	Alchemy runs under
`pnpm prisma …` / `npx prisma …`	Node	Node
`bunx prisma …`	Node	Bun
`bunx --bun prisma …`	Bun	Bun
`bun node_modules/prisma/dist/prisma.js …`	Bun	Node

The package-manager form is recommended. The deploy-cli design doc gains a Runtime section recording the invariant: Composer starts the launcher with Node and lets the launcher choose. CI and the examples never relied on Bun running Alchemy.

Verification

Tests, written first: pnpm with hoisting off, a hoisted layout, @prisma/composer not resolvable, no alchemy beside it, bin as a string, as an object without an alchemy key, and naming a missing file, a malformed and an unreadable manifest, the real workspace app; the Node lookup under Node, under Bun with node on PATH, under Bun without, Windows PATH splitting with quotes and PATHEXT; the reproduce command's quoting with pr-$USER, a backtick and a single quote; the spaces & symbols argument round trip.
cli (240) and core (240) package tests, root lint and typecheck, lint:deps, check:family-static-graph, check:cli-engine-pin, check:floor-imports, check:skill-packaging, test:scripts, lint:retired-binary-name, the store and criteria local-dev proofs.
Manual QA in a plain pnpm project with hoist-pattern= (strict isolation, no hidden hoist, no root alchemy), Composer from this branch's tarballs: prisma dev module.ts runs the alchemy beside @prisma/composer and reaches ready; under bun node_modules/prisma/dist/prisma.js Alchemy runs on the system Node; SIGINT gives an ok result and exit 130.

Alternatives rejected

Telling users to install alchemy. It is Composer's dependency; the app should not know it exists.
Resolving from the module's own location. It worked only because @prisma/composer-cli also pins alchemy, and could run a different copy from the one the stack file imports.
Resolving inside core. Core forbids node: imports by invariant.
Stripping Bun's environment variables so Alchemy always stays on Node. Nothing shows Alchemy failing under Bun, and fighting its launcher would be a second mechanism with its own drift.

Agent: columbo-17

🤖 Generated with Claude Code

prisma-gizmo · 2026-10-01T06:44:07Z

✅ Gizmo reviewed 7b54744 — posted 0 inline comment(s) this pass.

Open findings: 🟡 3 minor

Change walkthrough

This PR fixes prisma dev in plain pnpm projects, where the alchemy executable never started because node_modules/.bin only links a project's direct dependencies. Composer now resolves the alchemy package the same way the app's own @prisma/composer does (Node resolver from the app directory, nearest node_modules, run its bin entry with Node), so the executable and the generated stack file's imports come from one install by construction.

The reviewed delta (this pass). The incremental change is a docs amendment to the effect-version-conflict guidance, split per package manager now that the per-manager spellings matter more:

docs/guides/deploying.md:326-336 replaces the old two-line npm/Yarn note with three forms: npm's overrides in package.json, pnpm 11+ as a top-level overrides: block in pnpm-workspace.yaml (with the parenthetical that pnpm 11 ignores the pnpm field), and pnpm ≤10 nesting pnpm.overrides in package.json.
skills/prisma-composer-core-concepts/SKILL.md:517-520 compresses the same four-case summary into the failure-modes quick reference, staying consistent with the guide.

Updating both surfaces together follows the repo's .agents/rules/user-facing-surface-changes.mdc rule (guides are the website's content; the skill ships in the @prisma/composer tarball).

Rest of the PR (earlier pass, context). Core's devState() on @prisma/composer/local-target removes the generated stack file's direct alchemy import, fixing the same isolation bug one level down; the adapters now print the exact spawn command on deploy failure, replacing the fictional alchemy deploy … text; and the Runtime section of the deploy guide documents the Node/Bun matrix between the prisma bin and Alchemy's launcher.

coderabbitai · 2026-10-01T06:44:08Z

Important

🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Advanced
Run ID: 5583a168-35a1-4d53-9575-6467d35f2307

Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

pkg-pr-new · 2026-10-01T06:45:57Z

Open in StackBlitz

npm i https://pkg.pr.new/@prisma/composer@332

npm i https://pkg.pr.new/@prisma/composer-cli@332

npm i https://pkg.pr.new/@prisma/composer-prisma-cloud@332

commit: 7b54744

prisma-gizmo

New findings: 🟡 1 minor · trace

prisma-gizmo

New findings: none · trace

Still open from previous reviews: 🟡 1 minor

Both findings addressed in the follow-up commits; the bot's re-review reports no new findings.

prisma-gizmo

New findings: 🟠 1 major · trace

Still open from previous reviews: 🟡 1 minor

Findings outside the diff

🟠 Major · tests packages/0-framework/3-tooling/cli/src/tests/run-alchemy.test.ts — pnpmStoreLayout places alchemy in a store node_modules pnpm would never put it in, so the pnpm scenario the tests claim to cover is synthetic
The pnpmStoreLayout fixture installs the fake alchemy directly in the same store node_modules as the package whose file is passed as fromFile (@prisma/composer/dist/control.mjs), and the first test's name claims this is "an alchemy that is only a dependency of Composer". In a real pnpm project that layout cannot occur: a store node_modules (.pnpm/<pkg>@v/node_modules) contains only that package's direct dependencies, and the package that ships this module does not depend on alchemy — packages/0-framework/3-tooling/cli/package.json lists no alchemy; alchemy is a dependency of @internal/core (packages/0-framework/1-core/core/package.json:22), which lives in its own store dir that findAlchemyPackageDir's upward walk never enters. Since resolveAlchemyEntry() defaults to import.meta.url of this module (compiled into the CLI package's dist), the production walk under default pnpm actually succeeds via pnpm's hidden hoisted store (node_modules/.pnpm/node_modules, from hoist-pattern: ['*']) — a mechanism no test models — and under pnpm's strict isolation (hoist-pattern=false) it fails with DEPLOY.ALCHEMY_BIN_MISSING whose fix text names only Yarn Plug'n'Play as the unsupported layout. So the tests greenlight the PR's headline pnpm fix while validating a layout that never exists, and the config in which it still breaks is untested and undocumented.
Recommended fix: Make the fixture model the real chain: put the module that calls resolveAlchemyEntry() in its own package's store dir without alchemy beside it, and install the fake alchemy at <root>/node_modules/.pnpm/node_modules/alchemy (pnpm's hidden hoisted store). Add a case with the hidden hoist absent (pnpm hoist-pattern=false) asserting the DEPLOY.ALCHEMY_BIN_MISSING message, and mention that pnpm configuration in the error's fix text alongside Yarn Plug'n'Play.

prisma-gizmo

New findings: none · trace

Still open from previous reviews: 🟡 1 minor

…n link In a plain pnpm project that depends on @prisma/composer, `prisma dev` failed with DEPLOY.ALCHEMY_BIN_MISSING once the emulators were up: Composer looked for node_modules/.bin/alchemy, and pnpm links bins only for an app's direct dependencies. alchemy is Composer's dependency. This workspace hid the bug because its hoisted linker puts every bin at the root. resolveAlchemyEntry finds the alchemy package by walking node_modules up from Composer's own real location (alchemy does not export its package.json, so require.resolve cannot reach it), reads its bin, and the command line runs that entry with process.execPath. No shell shim is involved, so Windows needs no .cmd lookup. DEPLOY.ALCHEMY_BIN_MISSING remains for an alchemy that cannot be resolved, and its message now names the package lookup. Tests cover a pnpm store layout with alchemy only beside Composer and no .bin link, a hoisted alchemy, an absent one, and the alchemy this package is installed with. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

The deploying guide and the skill described the old .bin lookup, including the Windows shim order. They now say Composer runs the alchemy it is installed with, so an app needs no direct alchemy dependency. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

With the alchemy executable found, `prisma dev` in a plain pnpm project failed next inside the converge: the generated dev stack file imported alchemy/State/LocalState, and the app cannot resolve alchemy, which is Composer's dependency. @prisma/composer/local-target now re-exports localState, and the stack file imports it from there with the rest of its local-target imports, so it reaches the same alchemy copy the converge runs. The deploy stack file already imports only @prisma/composer entries. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

The skill and the deploying guide said one fix covers CONFIG.SECTION_MISSING, CONFIG.FIELD_RETIRED and CONFIG.FILE_RETIRED. SECTION_MISSING is fixed by adding the composer section; the two RETIRED codes by moving the old file's extensions and state into the section and removing configPath or the old file. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

Running alchemy's entry with process.execPath moved it onto Bun whenever the prisma host ran under Bun, as the examples and the e2e action run it. The old bin's node shebang kept alchemy on Node, on purpose. nodeExecutable now picks this process's runtime only under Node; under Bun it takes the first node on PATH, and raises the new DEPLOY.NODE_MISSING (added to ADR-0044's code list) when there is none. Tests cover both runtimes and the missing case with an injected runtime. The guide and the skill say alchemy runs under Node. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

… under pnpm `bun node_modules/.bin/prisma` fails in a default pnpm project, where that entry is a shell script. `bunx prisma` follows the node shebang and runs prisma under Node, and `bunx --bun prisma` also starts alchemy under Bun through its node shim on PATH. `bun node_modules/prisma/dist/prisma.js` runs the host under Bun with alchemy on Node, verified in a plain pnpm project. The guide and the skill document that form, keep the package-manager form for Node, and say why the shorter forms fail. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

- A Composer file that is not on disk (realpath fails) now raises DEPLOY.ALCHEMY_BIN_MISSING instead of a raw ENOENT. - The fix text says to check that alchemy is installed beside @prisma/composer, which depends on it, and that layouts without node_modules are unsupported, instead of sending users to reinstall. - The PATH lookup for node follows the injected platform: on Windows it splits on ";", unquotes entries and tries PATHEXT. - nodeExecutable's doc says Composer chooses the Node that starts Alchemy's launcher, which may move itself to Bun under bunx or bun run. - localState on @prisma/composer/local-target is marked @internal, for the generated dev stack only. - Tests: Composer reached through a symlink, a string bin, an object bin without an alchemy key, a bin naming a missing file, an unreadable path, the Windows PATH rules, a deploy stack file with no alchemy import, and a `spaces & symbols` stage round-tripping through the child on every platform. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

The guide and the skill claimed Alchemy always runs under Node and that the shorter Bun forms do not work. Alchemy's own launcher moves to Bun under bunx or bun run, and every form runs. Runtime now recommends the package manager's form (pnpm prisma, npx prisma), explains that Composer starts Alchemy with Node and the launcher may switch, and tabulates the four forms from the QA runs: package manager (Node, Node), bunx (Node, Bun), bunx --bun (Bun, Bun), and bun on the JS entry from a shell (Bun, Node). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

…LCHEMY_BIN_MISSING binEntryOf read and parsed the manifest unguarded, so EISDIR or a JSON syntax error escaped as a raw error instead of the structured diagnostic. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

…ecks The Bun-on-PATH case used the host platform and the real file system, so on Windows PATHEXT produced node.EXE where the test expected node.exe. Every case now injects its runtime, and Windows gets the default-PATHEXT and no-node cases too. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

This module is bundled into @prisma/composer and @prisma/composer-cli, and both declare alchemy, so pnpm puts alchemy in each package's own store directory. The fixture now models that with no hidden hoist and no root alchemy, for both packages. A package that does not declare alchemy gets DEPLOY.ALCHEMY_BIN_MISSING, and a test fails if the two published manifests stop declaring the same alchemy. The fix text names the package that runs alchemy under prisma and from a script. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

…aw localState re-export @prisma/composer/local-target exported Alchemy's localState directly, so an Alchemy upgrade changed Composer's public types. devState() is Composer's own name for the store prisma dev converges against. The dev stack header now describes the command Composer starts. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

…print the command that ran resolveAlchemyBin resolves @prisma/composer from the app directory, as the generated stack file's imports do, and takes the alchemy installed beside it. The CLI and the stack code then come from one install, wherever this module was bundled. Adapters report the command line they started, and failures print it as the reproduce command instead of an alchemy command that pnpm apps do not have. NodeRuntime is renamed HostRuntime, since the host may be Bun. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

… prints deploy-cli.md states the runtime rule: Composer starts the bin of the alchemy @prisma/composer depends on with Node, and Alchemy's launcher picks the final runtime. ADR-0007 gets an addendum for the printed reproduce command, and ADR-0044 notes that prisma dev raises the shared DEPLOY codes. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

prisma-gizmo

New findings: none · trace

Still open from previous reviews: 🟡 1 minor

Double quotes let a shell expand $, backticks and ! in a stage name when the command is pasted. Single quotes, with embedded single quotes escaped, keep every argument literal. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

…r-cli declares it The guide and the skill still said Composer finds alchemy from its own location. The composer-cli build config now says why alchemy stays a dependency: the inlined core code imports it, and the hoisted workspace would hide its removal. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

The lookup now anchors on the app's @prisma/composer (which declares alchemy) and the tests model pnpm's real strict layout; strict-isolation QA reaches ready. The bot's re-review reports no new findings.

prisma-gizmo

New findings: 🟡 1 minor · trace

Still open from previous reviews: 🟡 1 minor

cmd.exe reads single quotes literally, so the POSIX-quoted command broke when pasted on Windows. On win32 arguments are double-quoted with embedded quotes doubled; elsewhere they stay single-quoted. The family deploy test checked the bin path and arguments as one string, which failed on Windows because the temp path (RUNNER~1) needs quoting there; it now checks them apart. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

prisma-gizmo

New findings: 🟡 2 minor · trace

Still open from previous reviews: 🟡 2 minor

…hy a path gets quoted Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

prisma-gizmo

New findings: 🟡 1 minor · trace

Still open from previous reviews: 🟡 4 minor

…tput on cmd.exe Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

prisma-gizmo

New findings: none · trace

Still open from previous reviews: 🟡 5 minor

Addressed in later commits; the bot's re-review on 11b085c reports no new findings.

pnpm 11 ignores the pnpm field of package.json, so the guide and the skill now give the pnpm-workspace.yaml overrides block for pnpm 11 and later, keep the package.json form for pnpm 10 and earlier, and list the other package managers' forms separately. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

prisma-gizmo

New findings: none · trace

Still open from previous reviews: 🟡 5 minor

prisma-gizmo

All Gizmo review threads are resolved and the head commit has been reviewed. Approving.

prisma-gizmo Bot previously requested changes Oct 1, 2026

View reviewed changes

Comment thread packages/0-framework/3-tooling/cli/src/run-alchemy.ts Outdated

wmadden-electric force-pushed the one-config-file/remove-binary branch from be95770 to 07e3465 Compare October 1, 2026 07:52

wmadden-electric force-pushed the fix/alchemy-bin-resolution branch from eb0e77b to 061b536 Compare October 1, 2026 07:52

wmadden-electric force-pushed the one-config-file/remove-binary branch from 07e3465 to 840bb0a Compare October 5, 2026 10:00

wmadden-electric force-pushed the fix/alchemy-bin-resolution branch from 061b536 to 4dff2f8 Compare October 5, 2026 10:02

prisma-gizmo Bot reviewed Oct 5, 2026

View reviewed changes

prisma-gizmo Bot previously requested changes Oct 5, 2026

View reviewed changes

prisma-gizmo Bot reviewed Oct 5, 2026

View reviewed changes

Base automatically changed from one-config-file/remove-binary to main October 5, 2026 13:28

wmadden-electric and others added 14 commits October 5, 2026 15:33

wmadden-electric force-pushed the fix/alchemy-bin-resolution branch from 3496822 to 2ac4bea Compare October 5, 2026 13:33

prisma-gizmo Bot reviewed Oct 5, 2026

View reviewed changes

prisma-gizmo Bot previously requested changes Oct 5, 2026

View reviewed changes

Comment thread packages/0-framework/3-tooling/cli/src/run-alchemy.ts Outdated

wmadden-electric mentioned this pull request Oct 5, 2026

The host runs Composer 0.26.0: one config file, no prisma-composer binary (8.0.0-rc.20) prisma/prisma-cli#330

Merged

prisma-gizmo Bot previously requested changes Oct 5, 2026

View reviewed changes

Comment thread packages/0-framework/3-tooling/cli/src/family/__tests__/deploy.test.ts Outdated

Comment thread packages/0-framework/3-tooling/cli/src/run-alchemy.ts

docs(cli): name both cmd.exe characters quoting cannot protect, and w…

5236afb

…hy a path gets quoted Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

prisma-gizmo Bot previously requested changes Oct 5, 2026

View reviewed changes

Comment thread packages/0-framework/3-tooling/cli/src/__tests__/run-alchemy.test.ts

wmadden-electric and others added 2 commits October 5, 2026 16:12

Merge branch 'main' into fix/alchemy-bin-resolution

f16f066

test(cli): the quoting test title no longer promises fully literal ou…

11b085c

…tput on cmd.exe Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>

prisma-gizmo Bot reviewed Oct 5, 2026

View reviewed changes

prisma-gizmo Bot approved these changes Oct 5, 2026

View reviewed changes

Conversation

wmadden-electric commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The decision

Why it broke

The dev stack had the same bug one level down

What a failed deploy prints to reproduce

Which runtime Alchemy runs under

Verification

Alternatives rejected

Uh oh!

prisma-gizmo Bot commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change walkthrough

Uh oh!

coderabbitai Bot commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pkg-pr-new Bot commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Findings outside the diff

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

prisma-gizmo Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

wmadden-electric commented Oct 1, 2026 •

edited

Loading

prisma-gizmo Bot commented Oct 1, 2026 •

edited

Loading

coderabbitai Bot commented Oct 1, 2026 •

edited

Loading

pkg-pr-new Bot commented Oct 1, 2026 •

edited

Loading