Summary

Hi,

I'd like to understand why Turborepo docs/team suggest using .env instead of direnv. My team uses direnv but would like to use Turborepo and it's suggested best practices (using .env). I'd like to explain why we prefer direnv over .env so that maybe someone can convince me otherwise :)

Appreciate any advice experience Turborepo team or the community may have.

My team has chosen direnv over .env files because:

• once setup, you only have to cd into a certain package and all env vars are loaded into shell. Very simple.
• don't have to use --env-file or dotenv -- tsx src/app.ts in commands since env vars are automatically loaded
• More closely mirrors pipeline environment where env vars are automatically loaded. For example, in GitHub actions I define my env vars via GitHub Actions UI such that they're automatically loaded in pipeline environment. I don't have to setup .env files in pipeline so that I can use same commands/package.json#scripts which reference .env files which would not be there in pipeline.
• natively supports inheritance so that I can define global env vars once at root .envrc (direnv config file) and then inherit them in package .envrc files

The one downside to direnv is that the mechanism to load the .envrc files is in your .zshrc file so that it's not triggered when Turborepo or a script is running. For example, in order to run a deploy.sh we have to:

...
cd packages/app
eval "$(direnv export bash)"
pnpm run deploy
...

which is not ideal but this work around has been fine for now. This does prevent us from running commands like pnpm --recursive --filter "@myorg/myapp-*" though which would be convenient. Similarly it won't work for Turborepo.

Can someone explain their team's process for using .env files that provides as good of DX as direnv? What am I missing?

If we were to convert from direnv to .env, we'd need to:

• Write a script that generates a .env file per package with common env vars (recommended by Turborepo docs). We have over 50 packages so copying and pasting won't cut it.
• Convert all Node.js commands to include --env-file and non Node.js commands to use dotenv -- (ex: db port forwarding commands and python)
• Create separate commands for dev and pipeline. Don't think we'd have to duplicate command definitions though as we could reference our pipeline script within our dev script. For example: "deploy": "pnpm cdk deploy", "deploy:dev": "dotenv -- pnpm run deploy".

If we were to stick with direnv, how could we still using Turborepo? Can turborepo run eval "$(direnv export bash)" before each packages command is run? Is there an easy way to configure this?

Additional information

No response

Example

No response