Add JSON format for list outputs

[PrzemyslawKlys]

📖 Description

Adds --format json support for package listing output.

This enables machine-readable output for:

• winget list --format json
• winget upgrade --format json when used in list-only mode

The default table output is unchanged.

The JSON output includes installed package fields that match the existing list and upgrade table data, including package name, id, installed version, available version, and source. It also keeps JSON parseable for empty results and common error paths such as source-open failures, WinGet policy blocks, and generic execution failures.

winget upgrade --format json is intentionally limited to non-mutating upgrade listing. Commands such as winget upgrade --all --format json are rejected so package installation progress is not mixed with structured output.

🔗 References

Related to #1753.

🔍 Validation

Added focused test coverage for:

• JSON list output
• JSON upgrade-list output
• empty result output
• settings warnings before JSON output
• source-open failures
• WinGet policy blocks
• generic execution failures
• preserving help output for --format json --help
• rejecting JSON output for unsupported upgrade execution modes
• rejecting --details with JSON list output

Ran the focused AppInstallerCLITests scenarios for the JSON list and upgrade flows locally.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[florelis]

I don't think this implementation would scale well for extending it to the rest of the flows. As it is, any time we did any output, we would have to add a check for if we want JSON and do something different. I would prefer this to be handled in the Reporter as much as possible. For the tables in particular, the TableOutput could be extended to handle the output to JSON.

Maybe we should write a spec for this. Just to think out loud about what I think we could do for the implementation...

• We need to create schemas for all the objects we want to output, because people will definitely take a dependency on it and we can't break them later.
• We can add a flag to the reporter to tell it whether the output has to be text or JSON (or any other thing in the future)
• We would generally move away from passing strings directly to the reporter, and instead pass it objects that it knows how to format for each case. We would still output strings directly, but those would be more decorative (for example, "Installation succeeded" at the end) and the reporter would just discard them if it is using JSON.
  For example, for errors, we would pass an "error" object with an HResult and a message. For JSON it would add that as an object. For normal output it would print just the message. And then in both cases throw the HResult
• This would be too big to do in a single PR. We would add --format as an experimental argument, and then convert the output over time. If we set a flag in the Reporter to discard all normal strings when using JSON, it would initially return nothing for all commands, which I think could be a good default until we implement each one.

[denelon]

Is there a reason the Microsoft.WinGet.Client PowerShell module isn't suitable for JSON output?

I know several folks would like JSON output for WinGet, but generally that is because they want to build something that can use the JSON output like an API. We do have COM APIs, and we built the PowerShell module that is likely a better candidate for structured JSON output.

[PrzemyslawKlys]

Is there a reason the Microsoft.WinGet.Client PowerShell module isn't suitable for JSON output?

I know several folks would like JSON output for WinGet, but generally that is because they want to build something that can use the JSON output like an API. We do have COM APIs, and we built the PowerShell module that is likely a better candidate for structured JSON output.

This is answered in the linked issue by all the people asking for structured output. PowerShell is great but you are not delivering it as part of the system and having more outputs isn't going to bring too much of additional maintance.

[denelon]

I would want the "shape" of the JSON to conform with the PowerShell objects in either case if we are going to go down this path. As @florelis suggested, we should probably have a specification so we can capture this consistently. I would also want some kind of telemetry event to inform us when folks are using the JSON output so we can understand the usage patterns better.

We've been discussing internally something that could allow us to ship PowerShell in the packaged application, and we've reached out to the PowerShell team about how this might work and be extended to other packaged applications that also offer a PowerShell module. @SteveL-MSFT for visibility.