Problem

Right now we support an optional .env file that must live next to your schema.prisma file in the same directory. This coupling is a bit surprising and is often incompatible with how people want to organize their project.

Additionally, when you run prisma init, we write our env file to prisma/.env alongside prisma/schema.prisma. This layout works for us but is unusual and incompatible with projects that assume .env is in the project root. If you try moving prisma/.env into the project root, you'll also need to move prisma/schema.prisma to the project root. This approach is documented, but subtle.

For context, there are two components that rely on .env:

• The CLI when introspecting and migrating.
• The Client when connecting to the database.

Suggested solution

At the very least, we should allow .env in the project root and the schema.prisma in a prisma/ directory. This will allow people to re-use their .env that's already supported in Next.js, Redwood, Blitzjs, Create React App, etc.

Alternatives

Decouple .env and schema.prisma

It's not clear to me why we have this coupling between .env and schema.prisma in the first place. From my perspective,

• Client depends on DATABASE_URL being present by the time we connect.
• Introspect checks if the DATABASE_URL is in the environment at the time of introspection.
• Migrate checks if the DATABASE_URL is in the environment at the time of migration.

The CLI calls require('dotenv').config() in the beginning of the run. The Client doesn't do anything and expects the application to load the environment.

This would additionally allow us to properly support frameworks that use .env.test, .env.production. See #1717 for an example of this.

This solution would be my preference because it additionally solves #1717. (See Sept 24 Update)

Do nothing, suggest wrapping

Redwood & BlitzJS work around this problem by wrapping the Prisma CLI in their own CLI. This allows them to have the project structure they want without our limitations

I'm not advocating for this one, but it would solve the problem.

Related

• Change the prisma init default: Adjust prisma init to write to .env instead of prisma/.env #3721

Updates

Sept 24

Decoupling wouldn't completely add support for .env.test and .env.production in every case. For example, if you want to run the CLI with the test configuration (to migrate your test database), just calling require('dotenv').config() would load .env in all cases.

I don't think there's much harm in using something like require("dotenv-flow").config() as @flybayer suggested in the CLI to switch based on NODE_ENV.