Open
Description
This is a follow-up of dotenv support pr to track the development process, and answer some questions that require a general discussion for making the decision to implement them.
Todos:
- Precisely define the syntax of
.env
files, and consider a better format not based on ini - Supporting absolute paths for .env file src: do not coerce dotenv paths #51425
- Should we support multiple
--env-file
through the CLI? (cc @GeoffreyBooth) src: support multiple--env-file
declarations #49542 - Support multi-line values src: support multi-line values for .env file #51289
- Follow up after @tniessen's PR has landed to main test: improve
UV_THREADPOOL_SIZE
tests on.env
#49213 - Should we add a programmatic API? If yes, what would be the use-case? (cc @cjihrig) src: add
process.loadEnvFile
andutil.parseEnv
#51476
Questions:
-
Should we merge NODE_OPTIONS if both environment variable and .env version exist? Currently, we prefer environment variable over .env configuration.(cc @ljharb) src: merge env-file and env vars ofNODE_OPTIONS
#49217 - Should we throw if
.env
file does not exist? We currently follow the default behavior ofdotenv
package and do not throw. (cc @MoLow)
Please feel free to edit this issue in case there are more questions that needs to be answered.
cc @nodejs/tsc
Activity