Implement sort logic for winget list output

[Madhusudhan-MSFT]

Summary

Implements the sort logic for winget list output, completing the feature requested in #4238. Builds on PR #6177 (settings parsing + CLI handling).

Changes

Sort orchestration (WorkflowBase.cpp):

• SortInstalledPackagesTableLines — resolves sort fields from CLI --sort > settings output.sortOrder > query-aware default, determines direction, sorts via std::stable_sort, applies permutation back.
• When the free-text query (-q) is used and no sort preference is configured, relevance ordering is preserved. If output.sortOrder is configured, it is respected even with queries.
• FAIL_FAST_MSG for unrecognized sort field values — ensures invalid enum values crash loudly in debug builds.

Sort helper (PackageTableSortHelper.h/.cpp):

• SortablePackageEntry — holds pre-computed case-folded sortable fields, computed only for fields needed via ComputeSortFieldMask bitmask optimization.
• CompareByField — case-insensitive ordinal comparison using pre-computed FoldCase values.
• SortBy — template sort executor used by the workflow; standalone SortEntries wrapper available for unit tests.
• SortField enum uses flag-bit values (uint32_t) with DEFINE_ENUM_FLAG_OPERATORS for efficient bitmask field tracking.

CLI integration (ListCommand.cpp):

• --sort (repeatable, limit 6), --ascending/--asc, --descending/--desc arguments.

Argument validation (Command.cpp):

• Validates --sort values in ValidateArguments, following the --scope/--authentication-mode pattern.

Documentation (list.md):

• --sort, --ascending, --descending in options table. New "Sorting output" section.

⚠️ Behavior change: default sort order

Previously, winget list output preserved the source's natural ordering (source-determined relevance ranking). This PR changes the default to sort alphabetically by name (ascending) when no --sort argument, no -q query, and no output.sortOrder setting is configured.

Scenario	Behavior
No query, no settings, no --sort	Sorts by name (ascending) — new default
-q query with no sort preference	Preserves source relevance ordering (unchanged)
--sort relevance or "sortOrder": ["relevance"]	Preserves source ordering explicitly
"sortOrder": [] (empty array)	Same as no setting — applies default name sort
output.sortOrder configured + -q query	Settings override relevance (explicit user preference wins)

To restore previous (source-determined) ordering:

• CLI: winget list --sort relevance
• Settings: { "output": { "sortOrder": ["relevance"] } }

Note: An empty sortOrder array is equivalent to the setting not being present — it does not disable sorting. Use "relevance" explicitly to preserve source ordering.

Design decisions

Decision	Rationale
Default sort by name	When no settings and no query, sort alphabetically by name — most natural default for browsing installed packages.
Relevance preservation with queries	Free-text query (-q) without configured sort preserves source relevance ranking. Settings override this if configured — explicit user preference takes priority.
stable_sort	Preserves relative order for multi-field sorting (e.g., --sort source --sort name groups by source, alphabetical within).
Flag-bit SortField enum	Enables ComputeSortFieldMask to skip unused field extraction — measurable win for large package lists.
Pre-computed FoldCase	Expensive case-folding done once per entry at construction, not on every comparison call.
FAIL_FAST_MSG on invalid sort	Catches enum drift at development time rather than silent misbehavior.

How validated

Unit tests — 20 test cases:

• 18 sort tests in PackageTableSortHelper.cpp: single/multi-field sorting, both directions, edge cases, case-insensitive comparison, relevance no-op
• 1 drift detection test in Command.cpp: reads ListCommand::GetArguments() limit and validates against known ConvertToSortField strings — breaks if enum changes without updating limit
• 1 enforcement test in Command.cpp: verifies SetCountLimit(6) rejects 7 --sort values with TooManyArgError

Manual testing — 21 scenarios on wingetdev (Debug x64): defaults, single/multi-field sorts, direction flags, query + sort interaction, settings precedence, edge cases, invalid input. All passing.

Fixes #4238

[Trenly]

Is this only applicable to winget list or to any command that presents the user with a table of packages (upgrade, search, pin, etc.)

[Trenly]

Key behavior to note: Settings sortOrder is intentionally NOT applied when query/filter arguments are present. Only explicit --sort CLI arguments can override relevance ordering. The --descending flag applies to whichever sort fields are active (CLI or settings).

This seems like it would be counter to what a user would want. If I did winget list Microsoft and my default sort order in settings is Name I'd expect both the filter and the sorting to work

[Madhusudhan-MSFT]

Is this only applicable to winget list or to any command that presents the user with a table of packages (upgrade, search, pin, etc.)

The current implementation is scoped to winget list per the feature request in #4238. The sort infrastructure (schema, settings, argument definitions) was designed to be reusable, so extending to other table-outputting commands like upgrade or search would be straightforward if there's demand for it.

[Madhusudhan-MSFT]

This seems like it would be counter to what a user would want. If I did winget list Microsoft and my default sort order in settings is Name I'd expect both the filter and the sorting to work

This was discussed and agreed upon during the initial design. The intent is to preserve source relevance ordering for queries since a settings-based sort could push the best match down without the user realizing why. Explicit --sort always works with queries (e.g., winget list Microsoft --sort name).

@denelon — I believe this aligns with what we discussed during the design phase, would you mind confirming?

[Trenly]

if there's demand for it.

I think there is, but agree with the approach of limiting the scope for now and letting Demitrius figure out when to bring the rest in

• [New Feature]: Customizable sorting for search output #1769
• Output of the upgrade command should be sorted alphabetically #1352

[JohnMcPMS]

This seems like it would be counter to what a user would want. If I did winget list Microsoft and my default sort order in settings is Name I'd expect both the filter and the sorting to work

This was discussed and agreed upon during the initial design. The intent is to preserve source relevance ordering for queries since a settings-based sort could push the best match down without the user realizing why. Explicit --sort always works with queries (e.g., winget list Microsoft --sort name).

@denelon — I believe this aligns with what we discussed during the design phase, would you mind confirming?

From the design portion, my feedback was that the default behavior should be to remain unchanged with a query but could have a new ordering without a query. If the user does supply a setting value, my expectation would be that it would be used with or without a query unless overridden with a command line argument.

What constitutes a query? Probably only the actual query argument, not id or other fields. Relevance would largely by the same for those already.

[Madhusudhan-MSFT]

From the design portion, my feedback was that the default behavior should be to remain unchanged with a query but could have a new ordering without a query. If the user does supply a setting value, my expectation would be that it would be used with or without a query unless overridden with a command line argument.

What constitutes a query? Probably only the actual query argument, not id or other fields. Relevance would largely by the same for those already.

Thanks for the clarification, John. Updated in 70bd157e:

• Default unchanged — without output.sortOrder configured, positional query preserves relevance as before
• Settings always honored — if user configures output.sortOrder, it applies regardless of arguments (user explicitly opted in)
• "Query" narrowed — only the positional query argument (not --id/--name/--tag) is considered relevance-affecting in the no-settings case

Removed HasRelevanceAffectingArgs in favor of sortFields.empty() && Args.Contains(Query).