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.

What's Changed

• docs(design): ADR-0056 — prisma dev --serve runs a service's own dev command by @sneub in #377
• Name every node by its full address, starting with the app name by @wmadden-electric in #384
• feat(dev): prisma dev runs a service with its build adapter's dev server (ADR-0056) by @sneub in #381
• Set deploy's entry file in prisma.config.ts, not on the command line by @wmadden-electric in #387
• Add prisma deploy list: show every deployed node of a stage with its address and platform ID by @wmadden-electric in #388
• docs(design): ADR-0059 — a place the app runs is an environment, not a stage or a branch by @wmadden-electric in #385
• chore(release): v0.35.0 by @wmadden-electric in #389

New Contributors

• @sneub made their first contribution in #377

Full Changelog: v0.34.0...v0.35.0