If a comment isn’t part of the semantic content of a JSON object it has no business being there. JSON models data, it’s not markup language for writing config files.
For the data interchange format, comments aren’t part of the JSON grammar but the option to parse non-JSON values is left open to the implementation. Many implementations do detect (and ignore) comments indicated by e.g. # or //.
I’ve disagreed with JavaScript before, what makes you think I won’t do it again?
Anyway, anything using JSON as a config language will also certainly use a JSON interpreter that can ignore comments. Sure that’s “implementation specific,” but so is a config file. You wouldn’t use “MyApplication.config.json” outside the context of MyApplication loading its own configuration, so there’s no need for it to be strictly compliant JSON as long as it plays nicely with most text editors.
If a comment isn’t part of the semantic content of a JSON object it has no business being there. JSON models data, it’s not markup language for writing config files.
You can use comments in JSON schema (in a standardized way) when they are semantically relevant: https://json-schema.org/understanding-json-schema/reference/comments
For the data interchange format, comments aren’t part of the JSON grammar but the option to parse non-JSON values is left open to the implementation. Many implementations do detect (and ignore) comments indicated by e.g. # or //.
JavaScript package management promptly said otherwise. JSON is a config format no matter if you like it or not.
I’ve disagreed with JavaScript before, what makes you think I won’t do it again?
Anyway, anything using JSON as a config language will also certainly use a JSON interpreter that can ignore comments. Sure that’s “implementation specific,” but so is a config file. You wouldn’t use “MyApplication.config.json” outside the context of MyApplication loading its own configuration, so there’s no need for it to be strictly compliant JSON as long as it plays nicely with most text editors.