title | description |
---|---|
Architecture - Docs |
This plugin integrates Prisma into Nexus. It gives you an API you to project fields from models defined in your Prisma schema into your GraphQL API. It also gives you an API to build GraphQL root fields that allow your API clients to query and mutate data. |
import Image from 'next/image'
Understanding the following information should not be required knowledge for using Nexus Prisma. It is primarily here for internal maintenance and collaboration. But we're happy for whatever benefit you get out of it too.
- You or a script (CI, programmatic, etc.) run
$ prisma generate
. - Prisma generator system reads your Prisma schema file
- Prisma generator system runs the Nexus Prisma generator passing it the "DMMF", a structured representation of your Prisma schema.
- Nexus Prisma generator reads your Nexus Prisma generator configuration if present.
- Nexus Prisma generator writes generated source code. By default into a special place within the
nexus-prisma
package in yournode_modules
. However, you can configure this location. - Later when you run your code it imports
nexus-prisma
which hits the generated entrypoint. - The generated runtime is actually thin, making use of a larger static runtime.
When users choose a custom Nexus Prisma output directory the generated runtime needs to import the static runtime. There are a few things that need to happen in order for this to work:
- The output's imports needs to specify the package to import from
- The output's imports needs to specify the subpath to import from
For (1) we import from 'nexus-prisma'
. We just rely on the assumption that the user is outputting into a directory where eventually node_modules/nexus-prisma
will should up in the CWD path as Node module resolution algorithm executes.
For (2) we look if user is outputting ESM or CJS (gentime config) and based on that access either /dist-cjs
or /dist-esm
. In order to support this we need to break the encapsulation provided by package.json exports
field. We need to configure in it:
"./*": {
"default": "./*.js"
}
We cannot do something slightly cleaner either like this:
"./_/*": {
"require": "./dist-cjs/*.js",
"import": "./dist-esm/*.js"
}
Because ncc
, at least, does not support resolving .../_/...
imports to what is specified in the package exports.