Can there be a way to allow only json or ini but not both?
ljharb opened this issue · 8 comments
I'd like my project's config files to be in a consistent format. Can I pass an option to either disable json
or ini
parsing?
no but you can just not use one type ;)
Yes, but I want to require my users to only use one type. Is that a PR you'd accept?
Well, I'm always interested in how people use this module, so if you can make a case I will hear you out.
But I should say that I the point of rc is to be unconfigurable. I don't ever want to have to read custom configuration loading code, I just want simple that does what it needs to do.
I'd probably be a little more willing to be persuaded to just remove ini, but then I have no idea how many people use that (and lots of people use rc so probably some)
I was attempting to be diplomatic, but essentially what I want to do is disable ini
- I only want config files to be in json. The idea is that it will help me with debugging, so nobody will send me combo ini/json config files, as well as with any automated config file management tools that set custom keys, etc.
An opt-in setting somewhere that disables ini
support imo is a great start towards deprecating ini
support, defaulting the setting to true, and then eventually removing it, and would surface people's concerns in a timely fashion.
I would be more open to removing ini support than adding an option, but to be honest, I have no idea whether or how many people use ini config. I just use json. nobody has really posted issues about ini.
I only included it because npm uses it, so it seemed like a good idea at the time.
Hi, I just started to use the .ini format and it was one reason to use "rc" beside the perfect file locations/environment scan not conflicting with others (not like 'node-config', which can't be used in a module) - About .ini format: I think its easier to read & write for Sysadmins e.g. in /etc/ a .json file looks a bit strange and missing a comma or quote could destroy the file format ...
@megastef thanks, good point. It can be easy to fall into the trap of thinking that everyone is a javascript programmer, but that is not true.
Very old and closed discussion, but my two cents nonetheless :)
I totally like the ini format. It's just much more terse and consise. especially using the dot-notation in section names.
In my use cases, I typically have a rather complex and deeply nested default configuration. Typically, during development, you don't need to change/override anything.
However, in production, things need to be changed, especially now in times of docker and virtualization.
So, typically, just a couple of values need to be overridden, mostly they are deeply nested, and the change is often done by admins or other non-coders.
In this scenario, the ini format wins bigtime.
Overriding a single value means max two lines in ini format - no matter how deeply the value is nested.
In JSON format on the other hand, it depends on the level of nesting - the deeper the value is nested, the more noise you create with brackets and quotes and possibly new lines.
[orientdb.server.use]
port = 4000
vs
{
"orientdb": {
"server": {
"use": {
"port": 4000
}
}
}
}