[Settings] Add sort field and direction types for output ordering by Madhusudhan-MSFT · Pull Request #6176 · microsoft/winget-cli

Madhusudhan-MSFT · 2026-04-25T00:35:21Z

Summary

Add settings infrastructure for configurable output sorting in winget list. This is
part 1 of a 3-part stack that lays the type system and settings foundation without
changing any runtime behavior.

Part of #4238

Changes

SortField and SortDirection enums: Add SortField (Relevance, Name, Id, Version,
Source, Available) and SortDirection (Ascending, Descending) to the settings type
system. Relevance is internal-only and not exposed as a valid settings value.
Settings entries: Register OutputSortOrder and OutputSortDirection with typed
validation that maps JSON string values to enums using case-insensitive comparison.
Default sort order is [Name] ascending. Invalid field names reject the entire
setting and fall back to default.
JSON schema: Extend settings.schema.0.2.json with an output section containing
sortOrder (string array) and sortDirection (string enum with ascending default).
Static constexpr pattern: String constants for field name and direction comparisons
follow the established static constexpr std::string_view pattern used by
NetworkDownloader, LoggingLevelPreference, and other existing validators.

Impact

No behavioral change — settings are defined but not yet consumed by any command or
workflow. Existing winget list output remains unchanged.
Users who edit settings.json to add output.sortOrder or output.sortDirection
will have their values validated and stored, but the values will not take effect
until the sort logic is wired in a follow-up PR.

How Validated

Unit tests added: 16 test sections across SettingOutputSortOrder and
SettingOutputSortDirection test cases covering default values, single and multi-field
configurations, case insensitivity, empty array, invalid fields, mixed valid/invalid,
and wrong JSON types (62 assertions total).
Compilation verified for AppInstallerCommonCore and AppInstallerCLITests.

Follow-up

This PR is part 1 of a 3-PR stack:

PR1 (this): Settings types and schema
PR2: CLI arguments (--sort, --ascending, --descending)
PR3: Sort logic wiring, ConvertToSortField shared parser, and comprehensive tests

Microsoft Reviewers: Open in CodeFlow

…gs infrastructure ## Summary Introduce configurable output sorting for `winget list` as part of issue the sorting feature request. This is part 1 of a 3-PR stack that lays the type system and settings foundation without changing any runtime behavior. ## Changes - **SortField and SortDirection enums**: Add `SortField` (Relevance, Name, Id, Version, Source, Available) and `SortDirection` (Ascending, Descending) to the settings type system. Relevance is internal-only and not exposed as a valid settings value. - **Settings entries**: Register `OutputSortOrder` and `OutputSortDirection` with typed validation that maps JSON string values to enums using case-insensitive comparison. Default sort order is `[Name]` ascending. Invalid field names reject the entire setting and fall back to default. - **JSON schema**: Extend `settings.schema.0.2.json` with an `output` section containing `sortOrder` (string array) and `sortDirection` (string enum with ascending default). - **Unit tests**: Add 16 test sections covering default values, single and multi-field configurations, case insensitivity, empty array (disables sorting), invalid fields, mixed valid/invalid, and wrong JSON types. ## Impact - No behavioral change ╬ô├ç├╢ settings are defined but not yet consumed by any command or workflow. Existing `winget list` output remains unchanged. - Users who edit `settings.json` to add `output.sortOrder` or `output.sortDirection` will have their values validated and stored, but the values will not take effect until PR3 wires the sort logic. ## How Validated - Unit tests added (16 test sections across SettingOutputSortOrder and SettingOutputSortDirection test cases) - Compilation verified via msbuild for AppInstallerCommonCore and AppInstallerCLITests (compile-only)

…dators Follow established codebase pattern (NetworkDownloader, LoggingLevel) of declaring static constexpr std::string_view variables for string comparisons instead of inline string literals.

Trenly · 2026-04-25T00:56:53Z

Relevance is internal-only and not exposed as a valid settings value.

Is there a reason not to expose this? It feels like some users may specifically want this like if they want to sort by Source then by Relevance

Trenly · 2026-04-25T16:50:08Z

+        REQUIRE(sortOrder[0] == SortField::Name);
+        REQUIRE(userSettingTest.GetWarnings().size() == 1);
+    }
+    SECTION("Wrong type - number in array")


I'd also appreciate a test case for duplicate values, something like ["name", "id", "Name"]

Add test case verifying behavior when duplicate field names appear in sortOrder settings (e.g., ["name", "id", "Name"]). Duplicates are accepted and preserved — case-insensitive matching maps both "name" and "Name" to SortField::Name. Addresses reviewer feedback from PR microsoft#6176.

JohnMcPMS · 2026-04-27T17:23:40Z

Sorry, misclick...

Madhusudhan-MSFT · 2026-04-27T17:36:10Z

Good question @Trenly — relevance means "preserve the current natural ordering" (i.e., don't re-sort). It's internal-only today for two reasons:

sortOrder: ["relevance"] would be a no-op — identical to having no sort setting at all
Combining it with other fields (e.g., ["source", "relevance"]) isn't meaningful — once a primary sort reshuffles results, the original ordering is lost, so relevance as a tiebreaker would be non-deterministic and potentially confusing

If we were to expose it, it would only make sense as the sole value (e.g., sortOrder: ["relevance"]) to explicitly opt out of sorting — not combined with other fields.

@denelon — would you like us to expose relevance as a valid settings value (restricted to standalone use), or keep it internal-only?

denelon · 2026-04-27T18:07:03Z

I like the idea of exposing "relevance" since someone might want to have that documented and be able to put it in their settings.

… relevance, lowercase-once - Change OutputSortOrder default from [Name] to empty vector (sentinel for context-aware defaults: relevance when query, Name when no query) - Make Relevance a publicly visible sort field in settings and schema - Refactor OutputSortOrder validator to ToLower once then compare with == - Update tests for new default, add relevance field test section

Trenly · 2026-04-27T23:21:45Z

If we were to expose it, it would only make sense as the sole value (e.g., sortOrder: ["relevance"]) to explicitly opt out of sorting — not combined with other fields.

I suppose it depends on the use case? The 'Source -> Relevance' one makes sense to me, since you may want that as opposed to Source -> Name, but there is also a case where the match strength of several items is the same.

Take, for example, the case where I do winget search <query>. Relevance ordering places monikers first, then IDs, followed by product codes / commands / tags. I could see where a user may want to keep the relevance order there, but in each section have the results sorted by Name so that it would be something like this (Assuming Relevance -> Name)

Name	ID	Match
This Package	Example.One	moniker: query
Query Viewer	Query.Viewer
Four	Example.Four	tag: query
Three	Example.Three	tag: query
Two	Example.Two	tag: query

Madhusudhan-MSFT · 2026-04-28T00:10:47Z

Closing in favor of #6177 which now includes all changes from this PR plus the CLI argument registration. Reviewer feedback to consolidate into a single PR.

Madhusudhan-MSFT · 2026-04-28T00:24:31Z

This PR has been closed. All changes have been consolidated into PR #6177.

Madhusudhan-MSFT added 2 commits April 24, 2026 16:58

[OutputSort, Settings] Use static constexpr string views in sort vali…

f301115

…dators Follow established codebase pattern (NetworkDownloader, LoggingLevel) of declaring static constexpr std::string_view variables for string comparisons instead of inline string literals.

Madhusudhan-MSFT requested a review from JohnMcPMS April 25, 2026 00:37

Madhusudhan-MSFT mentioned this pull request Apr 25, 2026

[Settings, ListCommand] Add sort types, settings infrastructure, and CLI arguments for output ordering #6177

Open

Trenly reviewed Apr 25, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

Madhusudhan-MSFT force-pushed the user/masudars/list-sort-settings branch from ec489c4 to 184cacd Compare April 27, 2026 17:11

This comment was marked as duplicate.

Sign in to view

JohnMcPMS closed this Apr 27, 2026

JohnMcPMS reopened this Apr 27, 2026

JohnMcPMS reviewed Apr 27, 2026

View reviewed changes

Comment thread src/AppInstallerCommonCore/Public/winget/UserSettings.h Outdated

Comment thread src/AppInstallerCommonCore/Public/winget/UserSettings.h Outdated

Comment thread src/AppInstallerCommonCore/UserSettings.cpp Outdated

Madhusudhan-MSFT requested a review from JohnMcPMS April 27, 2026 18:45

Madhusudhan-MSFT marked this pull request as ready for review April 27, 2026 18:45

Madhusudhan-MSFT requested a review from a team as a code owner April 27, 2026 18:45

Madhusudhan-MSFT closed this Apr 28, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Settings] Add sort field and direction types for output ordering#6176

[Settings] Add sort field and direction types for output ordering#6176
Madhusudhan-MSFT wants to merge 4 commits intomicrosoft:masterfrom
Madhusudhan-MSFT:user/masudars/list-sort-settings

Madhusudhan-MSFT commented Apr 25, 2026 •

edited

Loading

Uh oh!

Trenly commented Apr 25, 2026 •

edited

Loading

Uh oh!

Trenly Apr 25, 2026

Uh oh!

This comment has been minimized.

This comment was marked as duplicate.

JohnMcPMS commented Apr 27, 2026

Uh oh!

Madhusudhan-MSFT commented Apr 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

denelon commented Apr 27, 2026

Uh oh!

Trenly commented Apr 27, 2026

Uh oh!

Madhusudhan-MSFT commented Apr 28, 2026

Uh oh!

Madhusudhan-MSFT commented Apr 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

Madhusudhan-MSFT commented Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Impact

How Validated

Follow-up

Microsoft Reviewers: Open in CodeFlow

Uh oh!

Trenly commented Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Trenly Apr 25, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment was marked as duplicate.

JohnMcPMS commented Apr 27, 2026

Uh oh!

Madhusudhan-MSFT commented Apr 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

denelon commented Apr 27, 2026

Uh oh!

Trenly commented Apr 27, 2026

Uh oh!

Madhusudhan-MSFT commented Apr 28, 2026

Uh oh!

Madhusudhan-MSFT commented Apr 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Madhusudhan-MSFT commented Apr 25, 2026 •

edited

Loading

Trenly commented Apr 25, 2026 •

edited

Loading