Switch `.env` file based on `NODE_ENV`

This issue depends on: https://github.com/prisma/prisma/issues/3720.

Problem

We don’t offer a native solution for switching environments when running the CLI.

A good illustration of this problem is if you want to migrate your test database, you need to run prisma migrate with your test environment.

Workaround

The current workarounds are to either provide the environment variables explicitly:

DATABASE_URL="db_test_url" prisma migrate

Or call your environment loader from the outside:

dotenv -e env.test -- prisma migrate

Or call the Prisma CLI from another script:

await execa("prisma", ["migrate"], { env: customEnv })

Proposal

Blitz, Next.js, Create React App support .env.*. This approach is nicely summed up on Next.js’s documentation

In general only one .env.local file is needed. However, sometimes you might want to add some defaults for the development (next dev) or production (next start) environment.

Next.js allows you to set defaults in .env (all environments), .env.development (development environment), and .env.production (production environment).

.env.local always overrides the defaults set.

Note: .env, .env.development, and .env.production files should be included in your repository as they define defaults. .env*.local should be added to .gitignore, as those files are intended to be ignored. .env.local is where secrets can be stored.

Source: https://nextjs.org/docs/basic-features/environment-variables#default-environment-variables

Concerns

We’re hesitant to implement this because:

• It’s a very specific solution to environment management. There’s a risk that this approach will change over time.
• Adds some runtime complexity to the client
• We want to make sure we support other environment loaders. For example, https://github.com/99designs/aws-vault.
  • This should already work, just need to test it.

Related Issues and Discussion

• https://github.com/prisma/prisma/issues/3720#issuecomment-704301413
• https://github.com/prisma/prisma/issues/1717

[NMinhNguyen]

Would be great if .env.local was supported out of the box (I don’t think that this particular feature needs to be opted in to).

[nephix]

First problem is that env vars need loaded from both .env and .env.production in this case and merged together.

I was able to make this work with dotenv-flow and dotenv-flow-cli and then in my package.json:

"db:reset": "dotenv-flow -- npx prisma migrate reset --preview-feature",
"db:migrate": "dotenv-flow -- npx prisma migrate dev --preview-feature",
"db:deploy": "dotenv-flow -- npx prisma migrate deploy --preview-feature",

It loads the main .env file and merges it with overwrites from e.g. .env.local or .env.production