Redwood: Is it good practice to have an .env file for seeding the database?

[jtoar]

While working on the Environment Variables doc (https://github.com/redwoodjs/redwoodjs.com/pull/229), I noticed we've got a Redwood app's api/prisma/seed.js setup to read an .env file in api/prisma:

https://github.com/redwoodjs/create-redwood-app/blob/fa59e843c94e67d6dbda01de2534da83516ffc39/api/prisma/seeds.js#L3-L5

// ...

const dotenv = require('dotenv')

dotenv.config()

// ...

The dotenv docs say it's bad practice to have multiple .env files. But I'm guessing things are a little different in this case? Just wondering why so I can add our reasoning to the docs.

[Terris]

I don't think it applies here. That code is loading variables from the same env file used for the rest of the app and, too, I believe the seed script runs in its own "process" or, you might say, "deployment" which is true to the spirit of the original article from which that recommendation was derived. Actually, I don't think the premise in that dotenv readme is a completely accurate decipherment of the original—which is neither here nor there :)

[cannikin]

This should actually be dotenv-defaults which loads .env if present as well as .env.defaults.

.env.defaults is meant to be variables that are safe to check into your codebase and values that can be shared between devs. .env is for the real secrets and values that are unique to each developer, and is not checked in.