Dentolize · Prisma CLI Devdependency Move Walkthrough
On this pageShort versionWhat could theoretically go wrong (and how to tell)What NOT to do

For Support

Short version

This change is invisible to end users and to clinic staff. It doesn't touch any screen, workflow, API response, or data. Support should not expect any tickets caused by this PR.

What could theoretically go wrong (and how to tell)

Because this edits a package.json used to build the server runtime image, the only realistic failure mode is a broken deploy — not a broken feature:

  • Symptom to watch for: the API fails to start, or a deploy/rollout

fails with a "module not found: prisma" or similar error when running a script that shells out to the prisma CLI in an environment that didn't install dev dependencies.

  • Where that could happen: only on a full-install machine that (a)

skips dev dependencies (--production) and (b) tries to run a prisma-CLI-dependent script like studio, push:no:use, or pro from inside packages/server. Per Feature breakdown, the current server sandbox image build doesn't use --production at all, and the deploy-host pro/rollout.sh scripts run a full (non-production) yarn install — so this specific failure mode shouldn't occur on any path this repository currently uses.

  • If it does happen: it would look like a build/deploy pipeline

issue, not a runtime bug reachable through the product UI. Escalate to engineering with the exact command and error rather than treating it as a user-facing incident.

What NOT to do

Don't spend time investigating clinic-facing bug reports (missing data, broken screens, slow queries) against this PR — it has no code path that could produce those symptoms. If a ticket seems connected to "something changed in a recent deploy," check other PRs in that deploy first.