JSON Formatted Output Support

[RichiCoder1]

Relevant area(s)

• WinGet CLI

Description of the new feature / enhancement

Parent / tracking issue for structured, machine-readable output in WinGet.

To enable automation and consumption by other tools, WinGet commands should be able to emit structured output (e.g. JSON) in addition to the default human-readable tables. Parsing the default console output is brittle; a stable structured format lets scripts and tools consume results reliably.

This issue tracks the overall effort; individual slices are tracked as sub-issues / related work below.

Scope

• A consistent --format json (and potentially other structured formats) across commands that produce output — e.g. list, upgrade, search, show, export.
• A stable, documented schema for each command's structured output.
• Where appropriate, keep the shape of the structured output (field names and structure) aligned with the objects returned by the WinGet PowerShell module, so consumers get a consistent schema across the CLI and the module rather than two divergent shapes.
• Well-defined behavior for empty results and error paths so output stays parseable.

Related work and sub-issues

• In flight: PR Add JSON format for list outputs #6346 adds --format json for list and upgrade (list-only) output.
• Provide Structured Data Format Options #1753 (closed) — original request for structured format options on list/upgrade; covered by the work above.
• More package information in Exported JSON file #2030 — richer package information in winget export JSON output (export payload).

Out of scope (separate concerns)

• Output verbosity — how much WinGet prints to the console (tracked in Client Verbosity Settings #161).
• Diagnostic log level — a distinct concern from output format.

---

Updated with GitHub Copilot.

[mikemaccana]

Modern Windows command line apps are in powershell, and already output structured objects. These can already be converted to JSON, Excel, CSV, or whatever other format is preferred.

The issue is that winget is unique, in that it doesn't output any structured data. #196 was created to address this issue but it was closed.

[RichiCoder1]

Mike MacCana (@mikemaccana) As mentioned on the other two issues, PowerShell isn't available in all Windows SKUs which this is targeting. For native PowerShell support, you're looking for #221.

[megamorf]

Richard Simpson (@RichiCoder1) Could you list all target SKUs and/or a link to the requirements spec, please?

[RichiCoder1]

It's been mentioned multiple times across multiple sources:

• Add Native PowerShell Support #221 (comment)
• https://twitter.com/richturn_ms/status/1262973495559876608?s=20

[denelon]

Richard Simpson (@RichiCoder1) I'm going through the backlog as a part of our planning exercise for the next few milestones. I'm going to close this as a Duplicate of #221.

Richard Simpson (@RichiCoder1) we've identified this Issue as a duplicate of another one that already exists. This specific instance is being closed in favor of tracking the concern over on the referenced Issue. Thanks for your report! Be sure to add your 👍 to the other issue to help raise the priority.

[RichiCoder1]

I'm cool with that as long as the ultimate functionality is still flexible enough to be consumed from other tools

[denelon]

Yes, that is the intent. Rather than building some kind of --output-JSON flag, the native PowerShell implementation will provide objects that may be used, and will not have the truncated output string behavior currently exhibited in the winget.exe client.