Moving the prisma CLI to devDependencies

Business view

Every Dentolize dependency package — a chunk of third-party code the project relies on — is labeled one of two ways: something the app needs to actually run (a "dependency"), or something only needed while building or developing the app, never at runtime (a "dev dependency"). The prisma command-line tool — the program engineers run by hand to change the database schema, or to open a visual database browser (prisma studio) — was filed under the "needed to run" label. It isn't; the running server never calls it. This PR re-files it under the correct label.

Why bother re-filing a label that doesn't change what the tool does? Because Dentolize spins up a fresh, disposable preview copy of the app ("a sandbox") for every branch under review, so a reviewer can click through the real feature before it merges. Building each of those sandboxes packages up whatever is labeled "needed to run" into a container image. A ~38 MB tool that's mislabeled gets copied into every one of those images, on every branch, for no benefit — pure waste of build time and disk space on the hosting machine. Correctly labeling it as dev-only is meant to let the sandbox build skip it.

Whether that saving actually shows up today is a separate question — see the Technical view below. The short version: on the current Dockerfile, the server image's build step doesn't use the flag that would make the label matter, so this particular saving doesn't land yet for that image. The label move is still correct and is a real prerequisite for the saving to land once that build step changes.

Technical view

The change

packages/server/package.json:226 moves "prisma": "7.4.2" from the dependencies object to the devDependencies object. That's the entire diff. No version bump, no other file touched.

packages/prisma/package.json:16 already declares prisma at the same 7.4.2 version under devDependencies. Because the resolved version is unchanged, the single shared yarn.lock entry (prisma@7.4.2: at yarn.lock:24874) is untouched — no re-resolution, no lockfile diff, no extra install step for anyone already checked out.

Where dependencies vs devDependencies actually matters

With Yarn classic (v1) workspaces, the distinction between dependencies and devDependencies only affects what gets installed when the install command passes --production. Without that flag, yarn install pulls in both sections for every workspace it touches, regardless of which one a package sits in.

Checking each Docker build stage in this repo's Dockerfile that could ship a packages/server/package.json-influenced image:

• server-runtime-deps (Dockerfile:288-308, feeds the server

runtime target at Dockerfile:351): copies packages/server/package.json and runs yarn install --frozen-lockfile --network-timeout 600000 --ignore-scripts — no --production flag. The stage's own comment (Dockerfile:303-306) explains this is deliberate: yarn install --production has been observed to skip packages that are genuinely declared in dependencies under this repo's Yarn 1 + workspaces setup (their example: @opentelemetry/api), so the team chose to trade image size for install correctness. Consequence: this stage installs devDependencies too, so moving prisma into devDependencies does not remove it from this stage's node_modules. This was confirmed live against the sandbox build of this exact PR — see the Walkthrough screenshot: node_modules/prisma is still present, still 41 MB, in the running server container.

• whatsapp-runtime-deps (Dockerfile:336-346, feeds the

whatsapp-official target at Dockerfile:380): this one does pass --production (Dockerfile:346). But it never copies packages/server/package.json into its build context at all — it only copies packages/whatsapp-official, packages/common, and packages/prisma manifests. packages/whatsapp-official/package.json doesn't declare a dependency on prisma (it depends on @prisma/adapter-pg instead, a different package). So this PR's edit is simply irrelevant to the whatsapp-official image — it was never affected either way.

• No auth-api stage exists. The Dockerfile header (Dockerfile:4-6)

states the auth-server target was dropped for this branch (no auth-server package present). The PR description's reference to an auth-api image doesn't match anything this Dockerfile builds.

Where the change does matter

• packages/server/package.json's own semantic correctness. The CLI

genuinely isn't runtime-required (@prisma/client — a separate, already-correctly-declared dependency at packages/server/package.json under dependencies — is what the running server imports). Filing prisma as a dev dependency is the accurate label regardless of what any particular Docker stage does with it, and it's a prerequisite for a future fix to server-runtime-deps (e.g., an allowlist-based install, or a reliable --production mode) to actually shrink the image.

• Any tooling that inspects packages/server's declared runtime deps

(dependency-audit scripts, SBOM generation, npm ls --omit=dev-style checks) now reports accurately that the server doesn't runtime-depend on the prisma CLI.

• The pro script (packages/server/package.json:94,

git pull && yarn install && yarn run prisma:migrate:deploy && ...) and rollout.sh/rollout-server.sh (deploy-host scripts) run a full yarn install with no --production flag, so devDependencies including prisma are present there regardless of this PR — deploy hosts are unaffected either way, matching the PR's "Compatibility" claim.

Net effect on this branch, as verified

The change is safe, semantically correct, and a reasonable step toward the stated goal — but on the Dockerfile as it exists today, it does not by itself reduce any sandbox image's size. See For Stakeholders for the impact framing and For Quality for what to verify before this is considered "done."