It's likely the switch to System.Text.Json that has caused this: #18141

Include a comment in json, one example can be seen here:

'{
    // A Json comment
    "string": "test"
}' | Test-Json

Unlike XML, JSON does not have a representation for comments, see The JavaScript Object Notation (JSON) Data Interchange Format.

What you have there is some JSON with a C++ style comment which is not part of the specification.

There are hundreds of JSON parsers and the only thing they have in common is the JSON specification. When you exchange JSON between different systems you risk parser failures if you don't stick to the spec.

README

@kyle-ntx, this selective switch to the System.Text.Json APIs is very unfortunate, as it is now at odds with the lenient rules of the JSON.Net APIs that still underly the ConvertFrom-Json cmdlet:

Specifically, the latter supports:

• unquoted property names
• single-quoted property values
• a single, extraneous trailing ,
• C-style comments - both to-end-of-line // comments and /* ... */ block comments.

Thus, there is now a blatant discrepancy between what ConvertFrom-Json accepts in practice, and what Test-Json flags as invalid - and while their behaviors definitely should align by default, there's not even an opt-in for testing strict adherence to the JSON spec. (seemingly not offered by JSON.NET - see #10628 (comment))

# All of these *succeed* with ConvertFrom-Json, but *fail* with Test-Json
@(
  '{ foo: "bar" }'
  "{ foo: 'bar' }"
  "{ foo: 'bar', }"
  "{ foo: 
    'bar' // bar it is
  }"
  "{ foo: /* et
    tu? */
    'bar'
  }"
) | Convertfrom-Json

While being lenient may sound helpful, in the words of The Fat Controller, it causes confusion and delay.

When passing JSON from one system to another you have no control over the other systems parser and should stick to the strict JSON specification. If you don't then you are basically passing garbage between one system and another and cannot trust any parser to interpret the data as you intended and may silently ignore some fields and accept others.

@rhubarb-geek-nz:

• It is indubitably desirable to have the option of performing a strict check for compliance with the JSON spec.

• Historically, Test-Json used the same APIs as ConvertFrom-Json, and the divergence discussed here therefore caused an unacknowledged and undocumented breaking change.

• It therefore makes sense for Test-Json and ConvertFrom-Json to continue to be aligned by default, and to offer a - yet to be implemented - opt-in to request strict compliance checking - not only via Test-Json, but also via ConvertFrom-Json.

Case in point: The Test-Json help topic still shows the following example as succeeding (which was true up to v7.3.x), which now fails:

"{'name': 'Ashley', 'age': 25}" | Test-Json

How to allow some kinds of invalid JSON with System.Text.Json

An example they give is

{
  "Date": "2019-08-01T00:00:00-07:00",
  "TemperatureCelsius": 25, // Fahrenheit 77
  "Summary": "Hot", /* Zharko */
  // Comments on
  /* separate lines */
}

So worth running the current failures through that to find the best set of options represent the original behaviour.

@rhubarb-geek-nz, from what I can tell, the System.Text.Json APIs fundamentally disallow unquoted property names as well as single-quoted property names and values (there's nothing in System.Text.Json.JsonSerializerOptions that suggests otherwise), so at least using these APIs directly won't work for emulating what ConvertFrom-Json accepts.

You might have to bite the bullet and have the ConvertFrom-Json Cmdlet supporting both parsers, where a switch selects which one to use.

Unlike XML, JSON does not have a representation for comments, see The JavaScript Object Notation (JSON) Data Interchange Format.

While this is true, it does appear that JSON with Comments worked before, and does not now, and the introduction of this change has broken scripts which we have relied on for quite some time.

I do agree that supporting things that are not part of a standard is fraught with danger, however, introducing a breaking change as part of a minor update and with out warning is not common practice and, if done at all, should be done with some forewarning and in the form of a major version change.

Looks like this can be fixed pretty easily, System.Text.Json allows skipping/ignoring comment literals in the input: IISResetMe@cc67613

@IISResetMe: As noted, this isn't sufficient: what System.Text.Json fundamentally lacks support for - unless I'm missing something - are unquoted property names and single-quoted property names and string values.

That is, it won't be able to validate something "{ foo: 'bar' }", which ConvertFrom-Json happily accepts.

I think what is called for is:

• Test-Json and ConverFrom-Json should exhibit the same, backward-compatible behavior by default.
• Ideally, extend them to support various syntax variants on an opt-in basis, notably allowing for enforcing strict adherence to the JSON spec.

Sorry for the lazy comment above @mklement0, I was solely referring to the comment parsing issue with Test-Json.

The following should evaluate without error with the suggested fix:

@'
{
  // this is a comment
  "property": "value"
}
'@ |Test-Json

... but obviously won't resolve the bareword/single-quote property name issue. Fully agree on backwards compat.

See also:

• Cannot parse the JSON. eror #21338 (comment)

@PowerShell/wg-powershell-cmdlets reviewed this. System.Text.Json.Node allows for options that would allow for comments. We believe that the default behavior should adhere to the standards (enabling portable JSON), but have a new -Option parameter which takes an array of options (currently would support Comments and TrailingComma).

@SteveL-MSFT, the proposed fix:

• doesn't acknowledge the fundamentally breaking change that occurred - see also: Cannot parse the JSON. eror #21338
• even with the opt-in doesn't fully restore the previous functionality, as System.Text.Json fundamentally does not support single-quoted tokens, and also doesn't support bareword properties.

Update: Just saw the following summary:

• Cannot parse the JSON. eror #21338 (comment)