multiple keys are not parsed

[robertkowalski]

i just realised that ini struggles with input like

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = [email protected]:joyent/node.git
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

(which is taken from a valid gitconfig)

in the ini notation multiple keys with different values are valid, but when ini parses them to JSON they get lost due to the limitations of JSON.

any ideas for a workaround or should i build a custom parser on my own instead?

[robertkowalski]

first idea that came to my mind is that ini could use arrays instead of objects as a parsing result

[isaacs]

Hrm, yeah, that is not great.

You're faced with:

1. Current state
2. Array-ify every value
3. Sometimes it's an array, sometimes it's a string (ugh)
4. All arrays all the time! Everything's an array! Tuples for the tuple gods!

[robertkowalski]

:)

tuples are great! we wrote whole databases in languages which just know tuples and lists of tuples!!!!11 all we had was tuples, tuples and lists - and our bare hands!

if i would bring tuples to the offering table - would you prefer it an option or a breaking change - the current format works in many cases but is also a dead end...

i am in favour of killing the object mode...

[isaacs]

Well, in cases like many config files, where subsequent options DO override earlier ones (as in npm's, where a key can only have a single value) it's exactly what you want. And if it isn't, then what you want is tuples all the way down, most likely.

It's only a couple hundred lines, so I'd recommend just writing a new module. The use case is different enough that supporting both will be annoying. Feel free to copy out whatever parsing code you want. It's all ISC licensed, so it's fine. If you take a lot, include a link in your license so the provenance is called out.

[robertkowalski]

yeah so the whole thing i built is named tulips, and i hate it :)

https://github.com/robertkowalski/tulips/

it is not feature complete (misses the subsection feature, e.g. [a.b.c], pull requests welcome).

it was enough for my use case (parsing .git/config files)