dominictarr/rc

Can there be a way to allow only json or ini but not both?

Closed 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
            }
        }
    }
}