Monorepo with three projects. There is a .env at the repo root with shared values, and each project has its own .env.staging. If both define API_TOKEN, which is used, and is that documented anywhere or just an accident of ordering?
Repo-root .env and a project .env both set the same name — which one is used?
Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
1 answer
Accepted answer
The project one, and it is deliberate.
Two roots are read, repo root first and then the project folder, and within each root four names in this order:
.env,.env.<env>,.env.local,.env.<env>.local. Every file is merged over what came before, so later assignment wins. That gives you, from weakest to strongest:- repo
.env - repo
.env.staging - repo
.env.local - repo
.env.staging.local - project
.env - project
.env.staging - project
.env.local - project
.env.staging.local
The root is for what every project shares; the project folder is for what one project needs, and it is more specific, so it wins. Missing files are skipped, and the whole stack still loses to an exported variable.
answered by Reeta NandalSDODS team- repo
Know the answer?
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.
Related
- Does colorScheme from the env use: block reach a recording, or only the runner?0 answers
- Locator fragility table is empty in insights but heal report has plenty of rows0 answers
- Audit wants proof the agents cannot write to our repo — what do I actually show them?2 answers
- Can --explain show the values a layer lost with, not just the winner?0 answers
- Six locales times dark and light means twelve env files — is there a per-scenario way?0 answers