New JSON parser in runtime

[troydai]

We implemented a new JSON parser in Microsoft.Framework.Runtime and removed the dependency on Newtonsoft.Json.

Using Newtonsoft.Json in the runtime prevents customers from choosing a specific version of Newtonsoft.Json in their applications. This change will allow customers to use any version of Newtonsoft.Json in their applications.

The new JSON parser is customized for internal use. It is used to parse only the project.json, project.lock.json and global.json files.

The new JSON parser doesn't support the following syntax:

1. Comments in the form of // ... and /* ... */
2. Trailing commas after the last member of objects and arrays

Other components, such as Microsoft.Framework.PackageManager, still use Newtonsoft.Json to parse JSON files.

[aspnetde]

Are there any plans to support comments (again)? I think that would be really helpful.

[LordZoltan]

Yeah while I agree with the change to remove the dependency on NewtonSoft at this low-level, given the importance of these json files, it's perhaps a little naive to assume that they won't need to be annotated with comments for the benefit of humans...
On 12 May 2015 22:05, Thomas Bandt notifications@github.com wrote:Are there any plans to support comments (again)? I think that would be really helpful.

—Reply to this email directly or view it on GitHub.

[NickCraver]

The lack of comment support is disappointing to say the least. Every developer I know following this was very excited about something with weight finally pushing for JSON comment support. This is really needed across the board - and I think Microsoft has a real opportunity to push adoption here with excellent reasons for doing so.

Every puppet configuration, hiera data file, or settings config we have here at Stack Overflow would benefit from comment support. I really feel you can and should push this. Older tools needing to read such files can run exclude comments via a regex before parsing if needed in the interim.

Please reconsider this. Comments are needed here, and in many, many other similar scenarios. This is an excellent use case to actually advance the JSON spec. Look at it this way: is there anyone who thinks JSON shouldn't support comments?

[stephen-riley]

Re: @NickCraver

is there anyone who things JSON shouldn't support comments?

No. :-)

Seriously, let's make this happen.

[Eilon]

Hi folks, we're not opposed to adding support for comments - we completely agree they are useful. However, we wanted to start out with a more "pure" solution to reading JSON by following the JSON spec as closely as possible. We currently chose not to implement optional aspects of the spec.

We will certainly revisit support for comments and trailing commas.

[mikeobrien]

[vcsjones]

I'll throw my vote in for supporting comments (trailing commas I can live without). I already have comments in my project.json file, and I would like to keep them. While "optional" I don't think customers will think of it as such. It's quite an omission.

[glen-84]

Microsoft should push for comments to be included in the JSON spec. The reasons for it not being included are weak.

And ...

The moment a parser expands the feature set, the document can no longer be parsed by other parsers. It's not at all intuitive that you can comment in project.json but not in bower.json or package.json. This is why it should be part of the spec once again, and why I thought it would be interesting to see how the spec writers would respond to such a request from a large corporation.

See aspnet/Tooling#13 (comment).

@Eilon Is this something that you could discuss with the spec writers?

[stephen-riley]

@Eilon , totally understand wanting to conform to the spec. However, the grammar for JSON with comments is a strict superset of the official JSON grammar, yes? In that case, what's the harm?

Addressing the link that @glen-84 sent out (good stuff there), we're not asking for VS2015 files to come standard with comments--by all means, leave comments out of the JSON documents that you want to be parseable by standard parsers. We just want the option of including them ourselves in our own files, totally taking on all risk and blame if our files break other parsers. "With great power..." and all that.