Open thejh opened 12 years ago
By default we simply follow the spec, but it wouldn't hurt to have as an option.
I guess I expect something with "lint" in the name to do some plausibility checking.
+1 Any chance this will get fixed? Also, I'd think it should complain about empty-string keys:
{ "": "foo" }
+1 just got bitten by a bug caused by a duplicate key, would love to use a tool such as jsonlint to catch these errors in my automated tests.
JavaScript, JSON, and Python all allow a key to be duplicated. (It is NOT a syntax error; the value of the last occurrence of the key is kept.)
JavaScript, JSON, and Python all allow the empty string as a valid key. (It is NOT a syntax error.)
So my vote is that these are NOT flagged as error or even warnings, unless the JSONLint user specifically calls for them via a commandline option.
@dharasty : what's the point of a lint tool if it doesn't catch anything more than the real parser? I think it's more than likely that there's an issue when there are duplicate keys...
@rngadam checking for duplicate keys was a big problem for me, and since this issue is still unresolved after 2 years, I had to bite the bullet and implement my own checker.
I agree with your position -- most people expect keys to be unique, key/value pairs to not be silently discarded, and the resultant object to match the JSON input. All of these reasonable expectations are broken, making debugging quite painful. :+1:
I see your points (@rngadam and @mattfenwick) and understand that if this as "bitten" you, you'd like a checker.
I guess I just don't use linting tools that way: I tend to use them to validate syntax and to pretty-format.
I do scratch my head a bit at "most people expect ... the resultant object to match the JSON input". I'm not sure what that means if the JSON input in the presence of multiple identical keys, which is allowed by in the serialization defined in the JSON spec, but clearly not in the concept of a JSON (or JavaScript) object. Therefore I'm not sure what is "reasonable" to expect.
I -- for one -- expect that repeated keys silently trump prior instances of the same key... but just because it it my experience that that is true (in JSON, JavaScript, and Python).
Is this your view?: "because purposeful use duplicated keys are very rare, when seen, it JSONLint should emit a warning".
+1
+1
I would also like to have jsonlint emit a warning on duplicate keys.
+1
It actually happened to me at least once that a duplicate key written manually by mistake caused a real bug, so it would be nice to get a warning about that. In my case I'd prefer that to be a fatal error in the build that would force me to fix it before deployment.
:+1:
100% agree. There is no reason to purposefully hard code duplicate keys in a JSON file. A linter should definitely check for this. Via an option is reasonable, considering it's not part of the JSON spec. Any chance this will get added? Need help creating a PR?
A pure JavaScript version of the service provided at jsonlint.com.
Judging from readme, this projects claims to work like jsonlint.com, but compared to jsonlint.com - it doesn't detect duplicates.
We use this library for linting manually written json files, and this problem caused confusion and time wasted more than once. I'd be happy to have it as an option if it shouldn't be the default behavior...
any chance to get this feature?
Finally, is there a check that supports duplicate keys?
Would love this.
Would love to see this also.
7 years later, still nothing?
9 years later, humanity is on the verge of extinction (COVID-19) - still nothing...(
OMG, this issue is still open.
I stumbled on this thread, for this exact problem.
The jsonlint-mod fork seems to solve that problem and exposes the same bin.
Posting here in case it helps someone else.
I know duplicate keys are valid, but I'd imagine most occurrences are a mistake and unexpected and unwanted.
https://github.com/prantlf/jsonlint seems to be maintained