If you have a security issue to report, please contact us at firstname.lastname@example.org with as much details as possible so that it can be handled confidentially.
Bug Reports and Feature Requests
If you have found a bug or have a feature request then please create an issue in this repository (please search first in case a similar issue already exists).
Prisma consists of a mono-repo for all TypeScript code. To setup and build the packages, follow these steps:
git clone https://github.com/prisma/prisma.git npm i -g email@example.com --unsafe-perm cd prisma/src pnpm i pnpm run setup
Note for Windows: Use the latest version of Git Bash
>=10.13minimum, latest LTS is recommended
yarn@1(for building a "pack" version of the client)
firstname.lastname@example.org(for installing npm dependencies)
docker(for managing test databases)
ts-node(for running Node scripts written in TypeScript)
Use TablePlus for managing sqlite database fixtures.
We use the Jest test framework. Its CLI is powerful and removes the need for npm scripts mostly. For most cases this is what you need to know:
yarn jest <fileNamePattern> -t <testNamePattern>
Some integration tests in these packages use Jest's
eachfeature. If you only want to run a subset of the test cases, simply leverage the
-tflag on the command line (see above point). For example in
packages/clihere is how you would run Just the
findOne where PKcases for sqlite integration:
yarn jest integrate.sqlite -t 'findOne where PK'
Also you can piggy back flags onto existing npm scripts. For example the above could be rewritten as:
yarn test:sqlite -t 'findOne where PK'
Developing Prisma Client JS
ts-node fixtures/generate.ts ./fixtures/blog/ --skip-transpile
For this step you might find our docker-compose setup helpful
npx prisma db push --preview-feature
We have two kinds of integration tests:
- Testing basic query functionality - located in src/tests/src/tests/integration
- Testing the client in mini projects - located in src/client/src/tests/integration
To run any of these, start the test databases (see readme for various ways to run these)
docker-compose up -d
General client integration tests (
The integration tests consisting of mini project are located in src/tests/src/tests/integration
Start the tests
pnpm run test
Prisma Client folder-based integration tests (
The integration tests consisting of mini project are located in src/client/src/tests/integration
Start the tests
pnpm run test integration
- To update the snapshots run script with Yarn and add
-uflag like this:
yarn run test -u
- If on a patch branch then the latest engine binary patch version for that semver-minor series will be used. If not on a patch branch then the current
masterengine binary version will be used. A patch branch is a branch whose name matches semver pattern
2.<minor>.x. The Test suite will log which engine binary is being used at the start of testing.
Creating a new integration test
Prisma Client JS integration tests are located in https://github.com/prisma/prisma/tree/master/src/packages/client/src/__tests__/integration
If you want to create a new one, we recommend to copy over the minimal test and adjust it to your needs.
It will give you an in-memory Prisma Client instance to use in the test. It utilizes the
getTestClient helper method.
Debugging a local project with your custom Prisma Client (aka
If you want to debug a project that you have on your local dev machine and run it with your local Prisma Client, we have something for you ;) The Prisma Client JS core authors need this all the time to debug projects, especially if databases like Postgres or MySQL are involved.
Click to expand
Let's say your project that uses Prisma Client is located in
~/reproduction/repro1. We got this fresh reproduction from a support engineer or a Prisma user.
- If you did not already, please go into
./src/packages/clientin your terminal.
- The magic script is located in
fixtures/generate.ts. It has a couple of different modes in which it can run, depending on your needs.
ts-node fixtures/generate.ts ~/reproduction/repro1
If you execute
ts-node fixtures/generate.ts ~/reproduction/repro1, a Prisma Client will be generated to
It is the nearest it gets to a "production" environment, in which it uses
npm pack of your local
client package. That means if you want to see any change in this approach, you need to run
yarn build every time, before you re-generate the client for your reproduction project.
yarn build is already quite quick, we might even have something faster for you:
Faster iterations (TS only):
ts-node fixtures/generate.ts ~/reproduction/repro1 --skip-transpile
In this case, we're not generating the Prisma Client as usual into
./project/node_modules/@prisma/client but just to
That means in your project you need to change the import. What is the advantage of this approach? You don't need to run
yarn build every time you have a change.
Note however, that this just works with TypeScript, as that client in
./@prisma/client directly imports the runtime from the
./src/runtime/ dir in your local client code.
You will need to have a
tsconfig.json in that project, with strict mode disabled. You can use the one of the blog fixture project.
Faster iterations (also JS):
ts-node fixtures/generate.ts ~/reproduction/repro1 --skip-transpile --built-runtime
In this case, you can still do
yarn build, but you don't need to rerun
ts-node fixtures/generate.ts ... all the time.
It will be a client, that again gets generated to
./project/@prisma/client (note that the node_modules is intentionally missing here) and points to the already built runtime dir in
./runtime in the client code.
With these 3 options you should be able to tackle any bug in any reproduction you get :)
Note, that sometimes you need to debug bugs in the
You'll need to build
yarn build if you want that change to end up in the reproduction project.
Working on code generation
If you have your local blog fixture running, you can now do changes to
TSClient.ts and re-execute
npx ts-node fixtures/generate.ts ./fixtures/blog/.
When doing changes and working on a fixture use
yarn build && rm -rf fixtures/blog/node_modules/ && ts-node fixtures/generate.ts fixtures/blog
Working with the runtime
If you want to use the local runtime in the blog fixture, run
ts-node fixtures/generate.ts ./fixtures/blog/ --local-runtime
query.ts will then be reflected when running
ENV Variables for debugging
|FORCE_PANIC_MIGRATION_ENGINE=1||Forces the Migration Engine to Panic|
|FORCE_PANIC_INTROSPECTION_ENGINE=1||Forces the Introspection Engine to Panic|
Developing Prisma Migrate
ts-node ../../src/bin.ts dev
prisma init Command
mkdir test && cd test
mkdir test && cd test
ts-node ../src/bin.ts generate
Running the Databases locally with Docker Compose
cd src/docker docker-compose up -d docker-compose logs -f app
Git Commit Messages
We structure our messages like this:
<type>(<package>): <subject> <BLANK LINE> <body>
feat(client): new awesome feature Closes #111
List of types:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
List of packages:
To Generate/Update install GraphViz
cd src ts-node scripts/graph-dependencies.ts
Pull Request authors must sign the Prisma CLA, it will show up in an automated comment after you create a PR.
If you cannot or do not want to sign this CLA (e.g. your employment contract for your employer may not allow this), you should not submit a PR. Open an issue and someone else can do the work.