Extend --env-file with support for INI sections

[vitaly-t]

What is the problem this feature will solve?

In our team, we embraced the use of --env-file right from NodeJS v20, it is an awesome addition!

However, in most cases the file that we pass in has INI format, which is quite expected. And INI files support sections ([section_name]), and we do not want NodeJS to push all values from all sections automatically into NODE_ENV, because some may end up overriding useful configuration inside NODE_ENV that's there by default.

What is the feature you are proposing to solve the problem?

For NodeJS to support optional section name(s), so only from those the values would go into NODE_ENV.

For example, supporting --env-sec, to take one or more section names, so only from those to load the variables:

--env-sec=sec1,sec2

Or alternatively extend --env-file syntax, say by appending # + section name(s):

--env-file=env/dev.ini#sec1,sec2

So above it would load env/dev.ini, and push everything only from sections sec1 and sec2 into NODE_ENV. I personally prefer the latter syntax, to avoid too many parameters to be passed in just for loading configuration.

What alternatives have you considered?

Without any such support, we have to split an INI file into several, one for NodeJS, and one for the rest of the application, which is a significant inconvenience.

Afterthought

As an extra benefit, such a feature would make it possible to consolidate environment configurations inside a single INI file when needed:

[dev]
DB_HOST=localhost

[prod]
DB_HOST=123.234.125.68

Presently, NodeJS will just end up with the last value as an override, which is against the INI logic. Sections need to be respected when they are used, since NodeJS already has partial support for INI files, in effect, so this addition would make it a complete support.

It would be sweet, if for the above example we could just specify:

node --env-file=env/config.ini#dev

[anonrig]

You can achieve the same thing by putting it into 2 different files and have 2 --env-file arguments in your run command.

Is there any other reason rather than cosmetic appearances for using an ini format?

[vitaly-t]

You can achieve the same thing by putting it into 2 different files and have 2 --env-file arguments in your run command.

That's not good. We have an INI file that lists variables for 20 servers, i.e. 20 sections, each repeating variable names (different values). Following your suggestion, I'd need to replace 1 file with 20. At the moment we parse that file, to supply correct section to PM2 module. NodeJS should be able to pick the right section for this to be usable. Splitting it into many files is a terrible option.

Is there any other reason rather than cosmetic appearances for using an INI format?

NodeJS already uses INI, effectively, it just doesn't recognize sections, which looks like a limitation that should be resolved.

[anonrig]

I'm not opposed to adding it, even though i don't see any use case for most regular non-power users, unless they have 20 env files like you do.

We have a custom parser, so contributions are welcome.