haydenbleasel
Consolidate env variables and remove package-level .env files
Is your feature request related to a problem? Please describe. Currently, some internal packages (e.g., packages/database, packages/cms, packages/internationalization) require their own .env or .env.local files. This adds overhead during setup and increases the risk of inconsistencies, especially when onboarding new contributors or deploying across environments.
Describe the solution you'd like I'd like to consolidate environment variable management by loading all required variables from a centralized file — ideally from the consuming application’s .env.local (e.g., app/.env.local, api/.env.local) or a new shared file at the root of the repo (e.g., .env.shared).
This would allow packages to avoid maintaining separate .env files entirely. Instead, they can rely on the parent process (next dev, node, etc.) to supply the required variables via process.env.
Minimal changes would be needed:
-
Document expected env vars in the consuming app’s .env.local.
-
Update packages to remove their .env loading logic, relying instead on process.env passed from the parent process.
Describe alternatives you've considered
-
Keeping .env files per package but auto-generating them during setup (adds complexity).
-
Using symlinks to a shared .env file (can be confusing on some systems or CI).
-
A shared config utility like @repo/config, but this would be too disruptive to adopt across already-large packages.
Before opening a PR, I’d like to confirm:
Would you prefer the packages rely on the closest consuming app’s env (e.g., api/.env.local), or should we standardize a shared root-level .env.shared or .env.local file for package-level envs?
How do you plan to handle scripts that need to be executed without a parent process ? For example, the build and analyze scripts from the database package.
