ini
ini copied to clipboard
npm
Parse all values, not only booleans and `null`
@piranna if you make the PR to https://github.com/rijnhard/ini-extra I'll review it.
One condition though, this should be a decode filter, it will also need to handle 0 prefixed numbers safely and not convert them.
One condition though, this should be a decode filter, it will also need to handle 0 prefixed numbers safely and not convert them.
What do you mean? There should not be problems with 0-prefixed numbers, but I don't understand the "not convert them" part. Shouldn't them be converted to decimal so when doing the stringify they are still in their original base? I don't believe this would be posible, since there's no way to store the original base... :-/
By the way, maybe you could find https://github.com/piranna/string2js interesting, if you think there's some formats that should be added, just tell me :-)
@piranna use case - a telephone number 0120001234 it's a valid string that should be starting with a 0. In this case it shouldn't be converted
@piranna it would mean a bit smarter handling of typed instead of blindly passing them to json decode.
@piranna sorry for the spam, it looks good, my only critiques are that it also doesn't handle that use case, and that moment is quite a large dependency, it would be better to try and avoid that dependency
@piranna use case - a telephone number 0120001234 it's a valid string that should be starting with a 0. In this case it shouldn't be converted
Very good point! :-D I though you were talking about octal or hexadecimal numbers. Hum, yeah, maybe they could be considered a string, don't think anybody would write a number leading with a zero in a ``.ini` file... Anyway, pone number I usually see them starting with a + sign, but it could be wrongly interpret with a number...
@piranna it would mean a bit smarter handling of typed instead of blindly passing them to json decode.
Yeah, I find it fair. I use JSON only as last resource, if a more specific one don't exists before.
@piranna sorry for the spam, it looks good, my only critiques are that it also doesn't handle that use case, and that moment is quite a large dependency, it would be better to try and avoid that dependency
I was not suggesting to use string2js, although would be nice, just only since you were so much concern about the formating and deserialization, maybe you could be able to provide advices about some more extra formats :-)
This would be a breaking change as-is unless gated behind a parameter. Closing due to age and the fact that it's not ready as-is (due to breaking nature of the change).
If this is still something folks need feel free to resubmit behind a flag.
