Switch `.env` file based on `NODE_ENV`
**This issue depends on**: https://github.com/prisma/prisma/issues/3720. ## Problem <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] --> 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: ```ts 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
Posted by matthewmueller on Oct 6, 2020, 3:18 PM
Tags
Related issues
- I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
- As I replied in another comment[1], it's their software, their choice.
- [Feature] Support external model integration via personal API keys and local LLMs (BYOK)
- > So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
- Feature request: support multiple named accounts per app/connector
- Support standalone Windows installer (`codex-setup.exe`)
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
support (SaaS)
I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
NewAs I replied in another comment[1], it's their software, their choice.
[Feature] Support external model integration via personal API keys and local LLMs (BYOK)
> So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
Feature request: support multiple named accounts per app/connector
Support standalone Windows installer (`codex-setup.exe`)
[feature]: Move OIDC back to self-hosted OSS(Plane Free)
I was running about 1000 machines on VMware in my previous career.
Switch `.env` file based on `NODE_ENV`
**This issue depends on**: https://github.com/prisma/prisma/issues/3720. ## Problem <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] --> 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: ```ts 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
Comments (0)
No comments yet. Start the discussion.