Only support .env file next to schema.prisma

[timsuchanek]

As of now, the prisma2 cli checks and uses a .env file in the current working directory. We will change this to only read a .env file which is in the same directory as the schema.prisma file.

As proposed in prisma/prisma-client-js#454, we want to introduce support for a .env file in the Prisma Client.
As we want to limit the .env file usage only to the scope of Prisma and not the whole application, as that's not the responsibility of Prisma, the .env file will only be used by the Prisma Client, if it is next to schema.prisma.

This change also has to be reflected in the prisma2 cli, it should only read a .env file, if it's next to the schema.prisma file, which is in most cases in the ./prisma directory.

[homoky]

It leads to need of two env files. Would suggest to revert it.

[huv1k]

I second this, it leads to worse developer experience overall.

[Jolg42]

@homoky @huv1k so you could call dotenv explicitly like this in your code:

Folder structure

npm install dotenv to install & add the dependency in your package.json

import * as dotenv from "dotenv";
import { PrismaClient } from "@prisma/client";

dotenv.config();

async function main() {
  const prisma = new PrismaClient();

  const users = await prisma.user.findMany({});
  console.log(users);
}

main();

Here I have only one .env file in my project root folder and everything works perfectly 😉

[pantharshit00]

@Jolg42 I think that has another side to it that we the cli don't generate client from the root .env file.

[huv1k]

@pantharshit00 yes, exactly this :) Now you can't use CLI commands with .env file located in different paths.

[dkozma]

Thanks for the dotenv solution, @Jolg42.

Regarding the CLI, if we can specify the location of the .env file using prisma2 generate such as:

prisma2 generate --env-file=.env

that would be helpful, since now I have to symlink my .env from the root, or have two files.

[homoky]

Provided solutions are great, but would not be better to keep things clean and simple?

[dkozma]

@homoky I wouldn't be against reverting this change either - I'm all for simplicity, and personally this change has caused more pain than it has solved.

[maartenraes]

Also in favor of reverting this, it breaks our pipelines because we use .env, .env.test and .env.production based on environments and during pipelines.

Since there's only support for a .env and not for different environments based on NODE_ENV it's a pain to maintain now.

[janpio]

and not for different environments based on NODE_ENV it's a pain to maintain now.

Can you elaborate on this in a new issue please? Might be an oversight of a use case we are not aware of and just didn't think about. Thanks 🙏

[maartenraes]

and not for different environments based on NODE_ENV it's a pain to maintain now.

Can you elaborate on this in a new issue please? Might be an oversight of a use case we are not aware of and just didn't think about. Thanks 🙏

Does this suffice? :-)
#1717

[janpio]

Absolutely - as soon as it is an explicit issue someone will think about it sooner or later.

[scriptcoded]

Is this change not supposed to go for prisma2 migrate? Should I raise an issue?

[janpio]

Yes, creating a new issue is almost always the solution if something else got closed. I am not super sure what you mean by "go for prisma2 migrate", so looking forward to read about it in a new issue @scriptcoded.

[dizzyn]

Please reconsider this feature - to keeping two .envs (one for prisma, one for the rest) is confusing. Or please make that backward compatible - read also the root one if exists.

[janpio]

@dizzyn You can put the .env fiel anywhere you want for Prisma Client, you just need to load it manually yourself if it is anywhere than in this default location where Prisma Client itself takes care of the loading.

[dkozma]

@janpio Is there a way to point to an .env file not in the default location when using the CLI tools (e.g. yarn prisma2 generate)?

[janpio]

No, but a request that would enable that is tracked in #1255 Please upvote it if you want this functionality and maybe leave a comment with your usecase.

[leohxj]

Prisma generate does not relay on env, right?
I pass special env when it runs.

[Jolg42]

@leohxj how do you pass the special env?

In 2.2.0 there is a problem with .env file loading with the CLI, this will be fixed in a patch next week. (#2981)

[leohxj]

@Jolg42 it is my mistake, I want to explant that prisma generate does not use env, prisma save/up use it.
but I remeber previous prisma version, generate also use env?? It should a bug that fixed.

[Jolg42]

So you probably hit the issue in your case, we will issue the fix on Monday :) Thanks!

[Jolg42]

@leohxj The issue is fixed in the latest version of @prisma/cli: 2.2.1

Related #2971

[leohxj]

@Jolg42 thanks

[gildniy]

I got them working with these scripts, as from this issue

    "start:dev": "cross-env NODE_ENV=development ts-node-dev --no-notify --respawn --transpile-only src/server.ts",
    "db:save-dev": "dotenv -e dotenv/development.env -- npx prisma migrate save --experimental",
    "db:up-dev": "dotenv -e dotenv/development.env -- npx prisma migrate up --experimental",

And I serve the environment variables from the config/env.js file:

const path = require('path')
const dotenv = require('dotenv')

const envPath = path.resolve(__dirname, `../../dotenv/${process.env.NODE_ENV}.env`)

dotenv.config({path: envPath});

const {JWT_SECRET} = process.env

export const envVars = {JWT_SECRET};