Switch environment file with `-e` flag

[divyenduz]

prisma2 -e .env-file

Use case, developing locally, deploying to lambda using serverless, my package.json would have the following script:

"deploy-production": "yarn prisma2 lift up --auto-approve && sls deploy --stage production",

To make it work without this, I need to do the following for all env vars

"deploy-production": "DB_URL=$(cat .env.production | grep DB_URL | cut -d '=' -f 2) yarn prisma2 lift up --auto-approve && sls deploy --stage production",

[schickling]

I like the idea but would suggest to call the argument --env-file same as Docker:

[timsuchanek]

In order to tackle this, we need to create a spec document first, which holistically describes our env var approach.

[sorenbs]

This is mostly relevant for Migrate, so we will not do any product work on this before the launch of Client.

[scriptcoded]

This would also solve the issue which arose since the change to how the .env file is located (https://github.com/prisma/prisma2/issues/1519) in preview022.

Right now we either have to write some loader script, or have the .env file in multiple locations. Neither is very appealing.

[dkozma]

This also seems relevant for making yarn prisma2 generate work with an .env in the project root (instead of the prisma folder) as discussed in #1519, unless someone else knows another way to run that without copying/symlinking my application's .env file to the prisma folder (or managing multiple .env files).

[divyenduz]

In the mean time, dotenv-cli can be used as a workaround. Just use that to load your .env file before calling prisma2 generate or any other prisma2 command. It works with npm/yarn scripts as well.

[jimsorock]

@divslinger got an example of using dotenv? Right now I am renaming my .env files before every deploy.

[zigzactly]

@jimsorock for prisma migrate am using something like dotenv -e prisma/.env.prod -- npx prisma migrate save --experimental Similarly for migrate up. Seems to work fine with dotenv-cli.

But i cant get a similar setup to work for prisma generate. It will keep targeting the default .env file.

[mjknight50]

I hate to pile on to the +1, but having a configurable env location would be really helpful.

All of our applications use a pretty standard /config/config.env that we lay down via our build for AWS. Adding this one off is annoying and makes it a harder sell to our team for adoption.

[matthewmueller]

Hi @mjknight50

What does environment switching look like with this setup?

• /config/production.env
• /config/development.env
• ...

Something like that?

[mjknight50]

Hi @matthewmueller In our shop, we lay down the different environmental variables via AWS Parameter Store while the image is built (Docker) and then pushed to AWS. It's a pretty conventional env file:

port=4300
whatever=foo

# MySQL
MYSQL_HOST=XXX
MYSQL_PORT=3306
MYSQL_USER=XXX
MYSQL_PASS=XXX
MYSQL_DB=XX

#here is some more config for something else like passport-saml

We grab the config file for each region (sandbox, production) via a script:

# get config file
aws ssm get-parameter \
--region us-east-1 \
--name "/custom-apps/${SECRETS_APP_NAME}/${SECRETS_APP_ENV}/config.env" \
--output text --query 'Parameter.Value' \
--with-decryption \
> /usr/src/app/dist/config/config.env

So, circling back to the original question or issue.
It would be ideal to have my connection string for Prisma just be a value in config.env and not a whole separate env just for Prisma.

Yes, I could add it in to the build process, but Prisma is kind of an outlier here as pointed out: https://github.com/motdotla/dotenv#should-i-have-multiple-env-files

Maybe I am missing something in the Prisma connection string options? I don't know...

[matthewmueller]

@mjknight50 thanks for clarifying your setup!

I think we may have you covered already if you ignore the .env file entirely or only use it for development. It depends a bit on your setup.

Assuming the following schema.prisma:

datasource pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

Case 1: If config.env loaded into the environment before your app starts, we can use DATABASE_URL in the environment.

DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public" node app.js

import { PrismaClient } from '@prisma/client'

const client = new PrismaClient()

Case 2: If config.env is loaded by the application using dotenv or some equivalent, you can load the environment before initializing the client

node app.js

import { PrismaClient } from '@prisma/client'

// Normally you'd do dotenv.load("./config.env") or something
process.env.DATABASE_URL = "postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"

const client = new PrismaClient()

Would one of these options work for you?

[mjknight50]

Ah, so as long as I set an environmental variable to DATABASE_URL we're good... no matter where or how.

Great, thanks! I apologize if you had stated this somewhere in documentation and I missed it. It seemed like I had to use the .env file the examples. It is clear now that Prisma is just looking for DATABASE_URL

Thanks for your time and help!

[zomars]

This would also help avoiding warn(prisma) Conflict for env vars for us who rely on symlinks for monorepo setups. #9726

[senghuotlay]

it would be great if we can just pass in

const prisma = new PrismaClient({url: process.env.DATABASE_URL})

[janpio]

@senghuotlay You can: https://www.prisma.io/docs/orm/reference/prisma-client-reference#datasourceurl