Also hit by this problem when try to use npm modules version as keys in configuration file

@SkReD @f0zi does turning off dot-notation completely not do the trick for you? I'm worried about the number of permutations it would add to configuration if we start allowing it to be configured on a feature by feature basis.

It would, but that's not what I would like it to do because I would still like the dot notation to work for command line arguments. It's only in the config file that it breaks when there are dots in keys, as in

{
    "server": {
        "port": 9000
    },
    {
        "www.example.com": {
            "more": "settings"
    }
}

... where I would still like --server.port to work without the dot notation breaking the "www.example.com" key up in three levels.

I don't mind if addressing the URL key from the command line does not work / does not do the right thing.

@f0zi what if we properly handled dot notation in config, but allowed this to be turned off?

or, we do handle it properly right now? or is it buggy.

Yes, that's what I was asking for in this thread. Also, I don't need it but I actually think it would be useful to set the character you split on, e.g. maybe have an option that is either a character or a bool (off).

I think it works as intended, but I'm not sure what the intention was and I don't think I agree with it. To me it's hard to justify changing the layout of a tree that is given to you based on some character in a key name. While I can see how it can be useful in certain circumstances, IMHO it should not be enabled by default. If someone wanted that feature, they could do it beforehand/afterwards, but if one does not want that feature and it's impossible to turn off then the only solution is to work around it like I explained in my top post.

Also, disclaimer, the product I needed this for is released and I might not actually change it even if you fix this. I do think that it would improve this otherwise great library if you would fix this though. :)

@f0zi I tend to agree with you about the API surface, I doubt that many folks are doing this:

{
  "foo.bar": "hello"
}

and expecting:

{foo: {bar: 'hello}}

Perhaps your original suggestion is the best route to take.

feel like submitting a patch adding config-dot-notation with a default value of false, and we'll make it a major?

I can try, I'm not sure if I'm up to it time-wise though.