feat(cli): add --format json to init and JSON-to-TS conversion#114
Conversation
init gains --format <ts|json>. The json format writes a dependency-free prisma.compute.json through the SDK's serializeComputeConfigJson with a $schema-first document, pins the same resolved values as the TypeScript path, and keeps the wx no-overwrite semantics. Because the format exists to be dependency-free, the types install step never runs with it and --install becomes a usage error; the custom framework is refused since strict JSON cannot carry the commented build stub init relies on. An explicit --format ts with an existing prisma.compute.json is the graduation path: the JSON config is validated, rewritten as prisma.compute.ts wrapping the same object in defineComputeConfig, the JSON file is deleted in the same operation, and the types install step runs. The reverse direction fails with INIT_CONVERT_UNSUPPORTED because TypeScript configs may contain logic a static file cannot express. Plain init still refuses every existing config with INIT_CONFIG_EXISTS. The result envelope now reports format and converted alongside configPath. The product decision asked for a --json boolean; that name is the global JSON-output flag on every command, so the config format rides a dedicated --format option instead.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Summary by CodeRabbit
WalkthroughThis PR adds a 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
…double-fault Review findings: init --format ts with an existing prisma.compute.json silently ignored --framework/--entry/--name/--http-port/--region; they now fail as a usage error since conversion transports values and never re-resolves them. If the post-write JSON delete fails AND the rollback delete also fails, the raw fs error escaped while two config files were left coexisting; that now surfaces as structured INIT_CONVERT_INCOMPLETE naming both files. Adds conversion tests for full field preservation (env, build, root, project region) and multi-app configs including a null build command.
Follows the SDK default flip: the schema URL does not resolve yet, so generated configs no longer reference it. The loader still strips a hand-added $schema, and emission returns as opt-in once the schema is hosted.
Drops the local link override now that 0.33.0 is published with the JSON config contract.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/cli/src/controllers/init.ts`:
- Around line 468-489: The conversion flag guard in
rejectConversionResolutionFlags currently only rejects
framework/entry/httpPort/name/region, so link-related flags are still accepted
during --format ts conversion even though they are ignored. Update
rejectConversionResolutionFlags in init.ts to include --link, --no-link, and
--project in the passed list (or alternatively plumb them through
resolveInitLink), so runInitConversion consistently rejects unsupported link
resolution options when converting an existing config.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: f5fa744f-86a8-46c9-b35f-ab1647f76572
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (9)
docs/product/command-spec.mddocs/product/error-conventions.mdpackages/cli/package.jsonpackages/cli/src/commands/init/index.tspackages/cli/src/controllers/init.tspackages/cli/src/presenters/init.tspackages/cli/src/shell/command-meta.tspackages/cli/src/types/init.tspackages/cli/tests/init.test.ts
Review follow-up: conversion already ran the install step like fresh init but silently ignored --link/--no-link/--project. The side-effect steps now behave identically to fresh init (resolveInitLink handles the already-linked short-circuit and non-interactive skip), while the value-resolution flags stay rejected since conversion transports values. Spec updated to state both rules.
luanvdw
left a comment
There was a problem hiding this comment.
@AmanVarshney01 thanks for this!
One edge I think we should look at before merging, conversion can find a prisma.compute.json in an ancestor directory, but the follow-up steps still seem to run from the directory where the command was invoked.
For example, if the repo root has prisma.compute.json and I run this from apps/api:
prisma-cli init --format ts --install --no-link --json
the command correctly writes ../../prisma.compute.ts, but the types/link side effects still use apps/api as the working directory. That means --install can miss the root package.json, and --project could write .prisma/local.json in the nested app directory even though deploy later reads the project binding from the config directory.
Could we make the conversion side-effect steps run against the discovered config directory, or pass that directory explicitly into the types/link helpers?
Review finding (Luan): conversion can discover prisma.compute.json in an ancestor directory, but the types install and project link still acted on the invocation directory, so --install could target the wrong package.json and --project could pin .prisma/local.json in a nested app dir while the config lives at the root. The side-effect steps now run against the discovered config directory via a context whose runtime cwd is the config's home; fresh init is unaffected since it writes at cwd. The reported configPath stays relative to the invocation directory.
|
@luanvdw good catch, fixed in 23b796d. The side-effect steps now run against the discovered config directory: conversion builds a derived command context whose runtime cwd is the config's home, so Covered by a new test that converts from |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/product/command-spec.md`:
- Line 399: Clarify the `--format json` behavior in the command spec by
separating the failure case from the successful skipped-install case. In the
sentence describing the types install step, use the same `--format json` and
`--install` wording but make it explicit that `--install` is a usage error when
JSON output is requested, and separately state that when `--install` is not used
the result reports the step as skipped with no install hint.
- Line 401: The graduation-path description overstates atomicity for the
`runInitConversion` flow. Reword the `--format ts` conversion behavior so it
reflects the actual sequence in `runInitConversion`: write `prisma.compute.ts`,
then delete `prisma.compute.json`, with rollback and `INIT_CONVERT_INCOMPLETE`
on partial failure. Keep the rest of the behavior description unchanged, but
avoid phrasing like “in the same operation” that implies the write and delete
are atomic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3eec133c-c8bc-4141-9d87-e5929e3c35c4
📒 Files selected for processing (3)
docs/product/command-spec.mdpackages/cli/src/controllers/init.tspackages/cli/tests/init.test.ts
…rsion delete semantics Review nits: the --format json sentence conflated the --install usage error with the skipped-step report, and "deleted in the same operation" overstated atomicity the INIT_CONVERT_INCOMPLETE error exists to handle.
Overview
prisma initgains a config format choice:--format <ts|json>. TypeScript stays the default (local dev environments get the fully typed experience, and init already installs the SDK);--format jsonwrites a dependency-freeprisma.compute.jsonwith a$schemareference for editor validation, the same format the Console setup PR commits (prisma/project-compute#103).Named
--format, not--json:--jsonis the global machine-readable-envelope flag on every command and cannot be repurposed.Changes
--format json: writes viaserializeComputeConfigJsonwith the same resolved values andwxno-overwrite semantics as the TS path. The SDK types install step never runs (the whole point is a dependency-free file);--installalongside it is aUSAGE_ERROR. Custom framework requires the TS format (its commented build stub cannot exist in strict JSON); fails with a structured error, nothing written.--format tswith an existing soleprisma.compute.jsonconverts it losslessly (validates through the shared normalizer, writesdefineComputeConfigTS, deletes the JSON; a failed delete rolls back the write so two configs never coexist), then runs the usual install step.--format json) is refused withINIT_CONVERT_UNSUPPORTED: TS configs may contain logic; converting is lossy.initwith any existing config still refuses withINIT_CONFIG_EXISTS; conversion is always explicit.result.formatandresult.convertedadded toInitResult; command spec and error conventions docs updated.Merge order
Draft until @prisma/compute-sdk 0.33 ships from prisma/project-compute#103. The last commit (
chore: link local compute-sdk pending 0.33 release) is a pnpm-workspace.yamllink:override for local dev and must be replaced by the real version bump before merge.Verification
pnpm --filter @prisma/cli test: 619 tests pass (10 new: json happy path with SDK-loader round-trip, conversion both directions, guard errors, custom+json, existing-config refusals)pnpm --recursive exec tsc --noEmit: clean;pnpm lint: cleaninit --format jsontheninit --format tsconversion theninitrefusal, all via the built CLI in a scratch dir