I am just trying to understand the documentation regarding environment variables at https://www.prisma.io/docs/guides/development-environment/environment-variables. The last paragraph states that I should load them manually at runtime, but I find that just importing PrismaClient does that automatically? So

import { PrismaClient } from "@prisma/client";
console.log(process.env.TEST);

will pull

TEST

from my

.env

file? Earlier the docs say

When you use Prisma CLI or Prisma Client, the .env file content and the variables defined in there are put into the system's environment, where Prisma can read it and use it.

When it says using Prisma Client, does that mean using PrismaClient in your code, as opposed to using some CLI command? I would prefer that it doesn't pull in stuff automatically, but I guess that just means I should not have any stray .env files lying around.

node does not use

.env

file by default, you can use this 3rd party module to load it: https://www.npmjs.com/package/dotenv but you don't have to use env at all, you can pass database URL manually:

export const prisma = new PrismaClient({
  datasources: { db: { url: 'my url' } },
});

I think I am just confused because even though I don't load the

.env

file using any 3rd party module, just importing the PrismaClient injects the

.env

content into my environment?

i don't think so, but if it does, i'd treat it as a bug, not as a feature 😄

I believe Prsma only uses the

.env

file for the

schema.prisma

file. file for the

I think my problem is that Prisma automatically loads the

.env

into my environment, whether I want it or not ... So I start with just Prisma installed, a basic

.env

file, and a basic model, and generate the database and client ...

> cat package.json
{
  "name": "test",
  "devDependencies": {
    "prisma": "^4.0.0"
  },
  "dependencies": {
    "@prisma/client": "^4.0.0"
  },
  "type": "module"
}

> cat .env
DATABASE_URL=file:./whatever.db
TEST=well hello there!

> cat schema.prisma
// This is your Prisma schema file,
// learn more about it in the docs: <https://pris.ly/d/prisma-schema>

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}

> npx prisma db push
Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Datasource "db": SQLite database "whatever.db" at "file:./whatever.db"

The database is already in sync with the Prisma schema.

✔ Generated Prisma Client (4.0.0 | library) to ./node_modules/@prisma/client in 361ms

I verify that I don't have

TEST

defined anywhere in my environment ...

> env | grep TEST

>

I create a simple app that just imports the PrismaClient (no dotenv, nothing) ...

> cat index.js
import { PrismaClient } from "@prisma/client";

console.log(process.env.TEST);

And when I run it, I expect it to print out

undefined

, but I get this ...

> node index
well hello there!

for me, that sounds like a bug, it's clearly a side effect, and it's not an ORM's responsibility to mess up with loading .env files

Thanks @PinkiePie, I was worried that I had the wrong expectations of what should happen.

@PinkiePie I could not agree more, however this is not a bug it's a feature, supposedly. I find it extremely annoying because I'd like to use

dotenv-flow

to manage variables for different environments however I abandoned my attempt at that as untenable due to Prisma's poor design decision IMO to load variables from a

.env

file.

@Chris Tsongas still not sure if this is a feature. Prisma could read

.env

file without polluting

process.env

. @nikolasburk is it a feature? Or should we maybe report it as a bug?

@PinkiePie not sure why you're confused, this is extensively documented behavior. Prisma even creates the

.env

file for you.

Apologies @PinkiePie - I was also of the opinion that it only read the

DATABASE_URL

from the

.env

(via some form of transversal) and not that it loaded everything. This doesn't seem too desirable..