Vscode: [settings] Use JSON5 instead of JSONC for configuration files

Created on 21 Jun 2020  路  17Comments  路  Source: microsoft/vscode




Currently configuration files are in JSONC format, which is a format without a specification, loosely standing for "JSON with comments". The VSCode version of it happens to allow trailing commas in arrays and objects, but this is a VSCode-specific implementation detail meant to make editing its own config files easier, rather than anything that is based on a specification. As such, VSCode config files are incompatible with other tools and tooling (and the fact that the file extension continues to be ".json" only exacerbates the problem).

I propose to use JSON5 instead of the more-or-less proprietary variant of JSONC (with .json extension, with trailing commas) that is currently in use in VSCode config files. JSON5 is a well-defined specification that includes comments, trailing commas, multi-line strings, single or double quotes, object keys without quotes and a couple other things borrowed from ECMAScript 5.1. It's still a strict subset of JavaScript and as such immediately understandable and usable for the vast majority of developers - in fact it could be argued that it's easier to understand than JSON, because it gets rid of some of the arbitrary and at times unexpected limitations that JSON imposes.

The most important thing, though, IMHO, is that Microsoft doesn't just forge its own path with proprietary implementations/extensions of JSON, creating essentially an "MS-JSON" variant, and instead embraces a cross-vendor, implementation-independent specification.

See also the discussion at https://github.com/microsoft/terminal/issues/4232

*out-of-scope feature-request settings-editor

Most helpful comment


:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

All 17 comments

Maybe while we're at it add support for YAML as well? (or strict-yaml)


This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

I agree that It needs changed but not to another JSON format. If it must be a JSON format, I do support JSON5 as the format over MSFT making their own.

If you support this issue please give a thumbs up to the description! It needs 20 upvotes by August 20 in order to be added to the backlog!


This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!


:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

Microsoft has provided much more robust tooling for dealing with JSONC than anything provided for the struggling JSON5 community. If Microsoft wants to help the community, please don鈥檛 stop them!

Just try to do some roundtrip work with the partially abandoned JSON5 project and you will quickly find out there is absolutely no support for it.

@brentonhouse helping "the community" (there's a JSONC community?) with tooling that only they themselves use?

If they had invested a similar amount of effort into moving JSON5 forward we wouldn't be having this discussion.

@mischkl - nope. It鈥檚 open-source and available for anyone to use. I use it in a lot of different projects and I would have never had the time to design, build, and test such an extensive library myself.

@brentonhouse what library are you referring to?

Ah, right. Now I recall seeing that, and it does indeed look useful. However I don't see any reason they couldn't extend that existing code with JSON5 capabilities.

My issue is not with the code they've written but rather with the fact that anyone outside of the Node ecosystem, or indeed anyone seeking an alternative to that exact library, is sore out of luck in terms of compatibility because there is no standard. It's already begun with MS submitting a patch to the jsoncpp library just to allow trailing commas in its Terminal config files - which of course is again limited to just one library that MS puts its weight behind, as opposed to anything standardized.

@mischkl - I actually used the JSON5 project early on in some of my projects but quickly found out that it is basically a personal project that wasn't updated much. Also, unless I am missing something, I see no way of actually updating JSON5 files using their library. There was one ticket that was closed back in 2016 but it doesn't look like that feature was ever implemented. https://github.com/json5/json5/issues/121. Without that, it is just a fancy way of reading JSON with comments and has little real-world practical value. If VS Code relied on using JSON5, how would the settings file get updated if you changed a setting using the GUI?

@brentonhouse to be clear, I am rallying for Microsoft to adopt JSON5 as a format, not for them to limit themselves to the reference implementation. Just like for advanced use cases hardly anyone would rely solely on Douglas Crockford's reference implementation of the JSON2 library.

They could for instance extend/fork the existing node-jsonc-parser library (seeing as JSON5 is essentially a better-defined superset of JSONC) and keep all existing format-roundtripping features.

I support @mischkl.

There is no standard of JSONC, just conventions. However, JSON5 is a format with spec.

With a clear standard, we can absolutely throw away the reference implementation, and do everything with confidence. But without it, to reduce inconsistencies between implementations, we have to check what others are doing quite often.

I've seen at least 5 projects struggling with it. Even VS Code itself has to keep a lot of lists to distinguish JSONC:
https://github.com/microsoft/vscode/blob/4c99db1a05687a67c1d214361946b18e5f65e0cf/extensions/json/package.json#L45-L61
https://github.com/microsoft/vscode/blob/23c359da9c23322741e6156afa2f7fbdf9be8f43/extensions/configuration-editing/package.json#L27-L45
https://github.com/microsoft/vscode/blob/f564bbd5172ca97d05158145c73e784c288e6188/extensions/typescript-basics/package.json#L40-L52

Besides, in history, "no standard" almost killed a number of languages.

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

We have currently no plans to change the format of the settings files.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

omidgolparvar picture omidgolparvar  路  3Comments

villiv picture villiv  路  3Comments

v-pavanp picture v-pavanp  路  3Comments

curtw picture curtw  路  3Comments

philipgiuliani picture philipgiuliani  路  3Comments