You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
node env file parsing supports keys compared to dotenv #58807
After some testing I noticed that node.js (--env-file and related) parses keys in env files differently than dotenv
Specifically dotenv doesn't support keys with spaces or special characters while node does
You can see what I tried in the screenshot below:
So I would love to understand if the current node.js behavior is the desired one, or if node should align with dotenv.
PS: dot env doesn't seem to document in details what keys syntax it supports, also in the dotenv repo's tests I could not really find any test around keys 😕
INI has a far more general purpose than the one for which it is used within NodeJS - just the environment variables. To that end, we should only read that which can be considered a valid environment variable name / value, and ignore the rest.
And from the example given, we definitely should exclude variable names that have: ", ', ?, !, >, %, ~, and no spaces!
We should allow: letters, digits, $, -, _ and dots. However, variable name should not start with a digit (similar to JS variable names)
In all, a valid variable should follow that of a JavaScript variable name, but also allow hyphens and dots in the name.
Here's example of regex patterns I used some time ago to implement valid variable + section...
For variable name: ^\s*([\w$][\w.$]*)\s*=\s*(.*)
For section name: \[\s*([\w$.-]+)\s*("(.*)")?\s*]
Here, I have marked the cases we want excluded, from your examples:
In addition, unlike dotenv, NodeJS should NOT handle any single or double quotes for the variable values, and simply consume the whole, that's it, no processing on that!
So I would love to understand if the current node.js behavior is the desired one, or if node should align with dotenv.
The only reference for the format accepted by Node.js has been "whatever dotenv does" (see, for example, #48890 (comment)). INI files are not supported since sections are not supported and string quoting might work differently. So unless the project decides to deviate from this now, I would assume that the behavior of dotenv is the desired one.
Activity
dario-piotrowicz commentedon Jun 23, 2025
cc. @anonrig , @vitaly-t 🙂
dario-piotrowicz commentedon Jun 23, 2025
PS: I'm mostly interested to see if we can get an agreement on what node should support so that we can:
vitaly-t commentedon Jun 24, 2025
INI has a far more general purpose than the one for which it is used within NodeJS - just the environment variables. To that end, we should only read that which can be considered a valid environment variable name / value, and ignore the rest.
And from the example given, we definitely should exclude variable names that have: ", ', ?, !, >, %, ~, and no spaces!
We should allow: letters, digits, $, -, _ and dots. However, variable name should not start with a digit (similar to JS variable names)
In all, a valid variable should follow that of a JavaScript variable name, but also allow hyphens and dots in the name.
Here's example of regex patterns I used some time ago to implement valid variable + section...
^\s*([\w$][\w.$]*)\s*=\s*(.*)\[\s*([\w$.-]+)\s*("(.*)")?\s*]Here, I have marked the cases we want excluded, from your examples:

In addition, unlike dotenv, NodeJS should NOT handle any single or double quotes for the variable values, and simply consume the whole, that's it, no processing on that!
tniessen commentedon Jun 24, 2025
The only reference for the format accepted by Node.js has been "whatever dotenv does" (see, for example, #48890 (comment)). INI files are not supported since sections are not supported and string quoting might work differently. So unless the project decides to deviate from this now, I would assume that the behavior of dotenv is the desired one.
anonrig commentedon Jun 24, 2025
I agree with @tniessen. We can take dotenv parser as the source of truth for such differences while we have env-file in experimental state.
doc: add new environment variables doc page
doc: add new environment variables doc page
doc: add new environment variables doc page