[wmadden-electric]

Release v0.35.0 (0.34.0 → 0.35.0). Merging this triggers the Publish to npm workflow.

Paste the release notes below into the GitHub Release by hand. The auto-generated notes come from PR titles, and those titles do not carry the upgrade steps.

The bump stamps 0.35.0 on every workspace package, its internal dependencies, the lockfile and the prisma-composer-core-concepts skill. check:publish-deps passes.

After it publishes, prisma/prisma-cli#371 moves the prisma binary to 0.35.0 and mounts prisma deploy list.

Release notes for v0.35.0

Use Composer 0.35.0 with the first prisma CLI release that bundles @prisma/composer-cli 0.35.0. Earlier prisma releases run the 0.34.0 commands.

Breaking: every node's address starts with the app name

A node's address is now its full path from the app name: shop.catalog.db, not catalog.db. The same string is its logicalId on the platform, the name of every resource Composer creates for it, and the start of its environment variable keys (COMPOSER_SHOP_CATALOG_…).

The first deploy with 0.35.0 moves an existing environment to the new names in place. Databases keep their rows, buckets keep their objects, generated secrets keep their values, and custom domains stay. Each database connection and bucket access key Composer made is replaced by a new one with new credentials, and your services receive the new ones in the same deploy. Anything outside the app that copied an old connection string or access key needs the new one.

What you have to change:

• serviceOrigin() takes the full address. Change serviceOrigin('api') to serviceOrigin('<app>.api').
• prisma dev url takes the full address too.
• Don't deploy an environment with Composer 0.34.0 or earlier after upgrading. The older version looks for the old names and recreates every resource, losing their data.

One case needs a manual step: an app with a module or service named like the app, directly below the root, can have a new variable key that an older version wrote for another node. The deploy then stops before changing anything, and tells you which variables to delete before deploying again. The steps are in Upgrading to addresses that start with the app name.

Breaking: the entry file is set in prisma.config.ts

prisma deploy and prisma dev no longer take the entry file as an argument. Set it once in the composer section:

composer: composer({
  entry: './module.ts',
  extensions: [prismaCloud(), nodeBuild()],
  state: prismaState(),
}),

Then run prisma deploy or prisma dev. --entry <path> overrides it for one run. prisma deploy module.ts now fails with CLI.INVALID_ARGUMENTS, and running with no entry anywhere fails with CONFIG.ENTRY_MISSING.

prisma dev runs a service with its own dev server

Under prisma dev, a Next.js service now runs next dev instead of its assembled build, so edits hot-reload and its logs appear in your terminal. A node() service can name its own dev command with node({ dev: [...] }). Each dev server gets the same environment a deployment would, on its own port.

New: prisma deploy list

$ prisma deploy list --stage pr-42
Address          Kind      Platform ID   URL
shop             project   proj_…        —
shop.api         service   cps_…         https://….prisma.build
shop.catalog.db  postgres  db_…          —

It lists every node an app has deployed on a stage, with its address, kind, platform ID and URL. Without --stage it lists production, and --json gives the same rows for scripts. It needs the prisma release that bundles 0.35.0.

Agent: victoria-52

🤖 Generated with Claude Code

[prisma-gizmo]

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

Open findings: none

Change walkthrough

This PR is the release bump for v0.35.0: it stamps 0.35.0 on the workspace root and on every workspace package — publishable, private, examples, tests, and website — rewrites every internal workspace: specifier to workspace:0.35.0, regenerates pnpm-lock.yaml to match, and updates the library_version stamp in the prisma-composer-core-concepts skill that ships inside the @prisma/composer tarball. It exists so that merging it triggers the Publish to npm workflow, which reads the root version and publishes the three packages/9-public packages under the latest tag.

How it fits the codebase. The change is exactly what docs/oss/versioning.md prescribes: one lockstep version across all 42 workspace manifests, regenerated via the bump-minor → set-version tooling, with the lockfile kept consistent for CI's --frozen-lockfile installs. It lands after #387 (entry file in prisma.config.ts) and #388 (prisma deploy list), whose breaking behavior the release notes describe.

[coderabbitai]

Important

• 🔍 Trigger review

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

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 93a17b25-4179-4764-b04b-28fdaad14fba

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

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

[pkg-pr-new]

Open in StackBlitz

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

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

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

commit: 9485ae6

[prisma-gizmo]

New findings: none · trace

[prisma-gizmo]

No Gizmo finding is open and the head commit has been reviewed. Approving.

[prisma-gizmo]

No Gizmo finding is open and the head commit has been reviewed. Approving.