Proposed changes: make bsconfig.json standard compilant

Hi all,

This is a proposed change that not going to happen soon, but I think it is worth moving in the direction in a major release.

Our bsconfig.json format is more flexible than JSON spec, i.e, it allows comments and trailing commas. It is indeed more convenient for users, so why not when I introduced bsconfig.json in the beginning?

At the same time, I learned lots of things in the last few years. In general, I believe it is a good tradeoff when exchanging some user convenience for easy/solid tooling. Having it standard compilant means you can query such data in your favorite programming language without any third party deps, it makes tooling easier.

How to be prepared for such changes?

Easy, just ensure your bsconfig.json is indeed a valid json format, this can be checked using your favorite editor, e.g vscode.

12 Likes

Good idea. I think that most people already have a valid JSON file.

Great idea. graphql-ppx parses the bsconfig.json for GraphQL specific configuration (like genType), and a user had a trailing comma and spend a few days debugging why the config was not working anymore.

Package.json allows extra keys to exist, so I use the extra keys to add inline documentation. There is a stack overflow thread that explains how to do it.

VSCode supports JSONC for its settings files with the .json extension JSON editing in Visual Studio Code

It doesn’t seem to be a standard yet but it is widely used because of that

I think this is a good idea.

In real-world-production-systems™, you often treat your configuration as a compilation target anyway. Generation of a compliant file, rather than worrying about discrepancies between parsers.

See e.g., Dhall, CUE.

I think that’s an awful idea. Pure JSON should never be used as anything else than a data interchange format. How about renaming it to bsconfig.json5? There are parsers for JSON5 in basically every language and I think it hits a sweat spot in terms of readability vs. simplicity (in comparison to e.g. YAML, which is a nightmare)