Development workflow

The branch / build / test / PR / merge cycle for prisma/prisma. Adapted from CONTRIBUTING.md and the workflows under .github/workflows/.

Branching

• The default branch is main. All work merges there.
• Branch names follow type/short-description (e.g., fix/migrate-status-typo).
• Two branch prefixes have meaning to CI:
  • integration/<name> — triggers the integration-tag release workflow (release-ci.yml) automatically on push.
  • factory/install-wiki-ci — reserved by the install-wiki skill.

Local build cycle

The fastest inner loop:

pnpm watch        # one-shot dev build, then watch all packages

If you only need one package:

cd packages/client
pnpm run dev      # esbuild only, no .d.ts

For a clean rebuild:

pnpm build        # turbo build, with type emit

The build is esbuild-based via helpers/compile/build.ts. Most packages opt in to bundledConfig from helpers/compile/configs.ts, which produces both CJS and ESM outputs plus type declarations.

Adding a new package

From AGENTS.md:

1. Create a directory under packages/<name>/.
2. Add package.json, tsconfig.json, tsconfig.build.json, and helpers/build.ts.
3. The package is auto-discovered via pnpm-workspace.yaml's packages/* glob.
4. For type-only packages, use bundledConfig from helpers/compile/configs.ts.
5. Add it as a dependency to consumers using "workspace:*".
6. Add the resolution path to tsconfig.build.bundle.json under compilerOptions.paths so editor go-to-definition works.
7. If the package has tests, add it to .github/workflows/test-template.yml in the appropriate job: others, client-packages, driver-adapter-unit-tests, or no-docker.

Pre-release on the integration tag

Branches starting with integration/ and PRs with /integration in the description trigger release-ci.yml. It publishes packages directly to npm under the integration tag with a version like 5.3.0-integration-fix-all-the-things.1. Useful for testing real Prisma behavior in real downstream projects without merging.

You can also manually trigger the workflow from the Actions UI on any branch (Run workflow → check "force an integration release for any given branch name").

Reviewing

• All PRs go through the @prisma/orm-ts team per .github/CODEOWNERS.
• Reviewers check tests, CI status, the bundle-size comment, and that AGENTS.md is updated when contributors learned something new.

Merging

• Squash-merge is the standard pattern.
• Engine version bumps are merged frequently and almost always by Prismo/prisma-bot via update-engines-version.yml.
• Stale issues are auto-labeled by label-stale-issues.yml. PRs themselves are not auto-closed.

Releasing

Production releases are driven by release.yml. The release implementation is in scripts/ci/publish.ts, which pnpm publish-all and pnpm publish-all-dryrun shell out to. pnpm status and pnpm pull proxy through the same script.

The dist-tag manager workflow (manage-dist-tag.yml) updates latest/dev/integration tags on npm.

Bumping engines

pnpm bump-engines runs scripts/bump-engines.ts. The check pnpm check-engines-override (scripts/check-engines-override.ts) protects against accidentally shipping a local engines override (used during contributor work — see Custom engines if needed).