Ability to lint files w/ JSON comments

[pdehaan]

I'm trying to lint some JSON files that happen to have some comments in JSON like this:

// this is configuration specific to aws deployments
{
  // disable statsd for aws
  "statsd": {
    "enabled": false
  }
}

But the $ jsonlint config/aws.json command gives me the following:

$ jsonlint config/aws.json
[Error: Parse error on line 1:
// this is configura
^
Expecting 'STRING', 'NUMBER', 'NULL', 'TRUE', 'FALSE', '{', '[', got 'undefined']

I'm not sure what libs mozilla/persona is using to load the commented JSON, but a bunch of the files are failing jsonlint due to the comments.

[bausmeier]

👍

[pdehaan]

If I understand this abyss correctly, these commented configs are loaded via convict which seems to use cjson which handles the commented JSON:

Commented Javascript Object Notation. It is a JSON loader, which parses only valid JSON files, but with comments enabled. Useful for loading configs.

[fritzblue]

+:100:

Comments are not (always) evil.

[NikolayFrantsev]

+1

[Asher256]

+1

[Arcanemagus]

That isn't valid JSON though... as evidenced by the nice bright red highlight GitHub is giving it 😛.

If this is ever implemented it should be disabled by default behind a flag...

[paleite]

@Arcanemagus What makes you say that?

[Arcanemagus]

@paleite This is jsonlint, not cjsonlint. I would expect jsonlint to properly validate something given to it as fully compliant JSON, so I can send it anywhere JSON is expected, and it will work. Comments and other "extensions" are not valid JSON and should be marked as an issue by default.

[lonix1]

@Arcanemagus You're right, it should be disabled behind a flag as you said. But it is a useful feature and should be available.

In a large project with many team members, I've found json to be commented more often than not.

[prantlf]

I needed some bugfixes and extensions to jsonlint and did them in my fork. I released the changes as a new NPM module @prantlf/jsonlint. Recognising and ignoring JavaScript-style comments in the JSON input was one of them. I made the support for comments optional, as an opt-in feature.

[iandunn]

It may not technically be valid, but I wouldn't say it's invalid either.

Douglas Crockford (creator of JSON) has said:

A JSON encoder MUST NOT output comments. A JSON decoder MAY accept and ignore comments.

Comments were initially allowed in JSON, and were only removed to prevent people from adding parsing directives.

There's no reason that decoders can't allow and ignore comments. Since some do just that, I think it makes sense for JSON linters to provide a flag that will let them pass through as well. The user will know best what their particular use case allows.

[lonix1]

The "json should not have comments" argument is long dead. I rarely see uncommented json anymore in commercial code (as opposed to open source code, which is fast and loose and not easily maintainable).

[mohkale]

More than dead. The spec finally added support for it to json5, kicking and screaming all the way 😄.

[hugovk]

Comments sometimes show up in TypeScript config tsconfig.json, support added in 2015:

• Allow comments in tsconfig.json microsoft/TypeScript#5450
• Allow comments in tsconfig.json microsoft/TypeScript#4987
• https://web.archive.org/web/20160323065910/http://blog.getify.com/json-comments (archive of article referenced in issue)