Microsoft’s Windows Package Manager 1.28 release candidate finally lets you flip a source between explicit and implicit with winget source edit, and the new --details switch turns the cramped table view of winget list into a full‑blown package report. The “source edit” subcommand rewrites the local settings file so winget can ignore an unavailable custom feed, which is handy after driver updates that break custom sources.

Windows Package Manager 1.28 Release Candidate: Using list --details and the New source edit

The latest release candidate for the Windows Package Manager 1.28 release, adds a couple of commands that actually make day‑to‑day usage less annoying. This guide shows how to toggle a source between explicit and implicit with the new source edit subcommand, and explains why the long‑awaited list --details flag finally deserves a spot in your toolbox.

Switching a Source’s Explicit State

When a source is marked “explicit,” winget treats it as a mandatory location for every install request. In practice that means you’ll see a flood of “source not found” errors if the server goes down. The new winget source edit <name> command flips that flag without digging through JSON files.

Why bother? A common scenario shows up after a driver update that silently replaces the Microsoft Store’s certificate. Users who previously forced the winget-font source to be explicit end up with broken font installs every time they run winget install. Running winget source edit winget‑font flips it back to implicit, letting winget fall back to its default sources when the custom feed is unreachable.

The command works because it rewrites the source entry in the local settings.json, updating the "Explicit" property. After the change, a quick winget source list confirms the new status, and subsequent installs stop spamming “source not found” messages.

Getting Full Package Info with list --details

The plain‑old winget list output is a cramped table that leaves out everything you might actually want to see—like install location or upgrade path. Adding --details turns each entry into a mini‑report, similar to the classic wmic product get but far cleaner.

Running winget list --details pulls the full set of metadata from the registry and formats it as a series of key/value pairs. The extra verbosity is useful when troubleshooting a stubborn app that keeps reinstalling itself after an update. For example, one user discovered that Visual Studio kept rolling back to an older version because the “Installed Scope” was listed as User instead of Machine. The detailed view exposed the mismatch without digging through Control Panel.

The flag also surfaces hidden fields such as Product Code, which can be fed directly into msiexec /x {code} for a silent uninstall. If you only need to know whether an app is present, the plain list is fine; but when you’re hunting down orphaned files or mismatched registry entries, the detailed view saves a lot of guesswork.

When the New Features Feel Like Bloat

Not every addition to winget earns its keep. The source edit command only matters if you manage multiple custom feeds—most home users never touch that part of the configuration. Likewise, list --details produces a wall of text for systems with dozens of apps; pairing it with findstr /i "visual" (or PowerShell’s Select-String) is essential to keep the output manageable.

If you’re looking for a graphical alternative, the built‑in Windows Settings app already lists install locations and versions. Running winget just to see that information feels like using a screwdriver to open a can of beans—possible but unnecessary.

You can download the release candidate from the linked Github page below:

Release Windows Package Manager 1.28.190

This is a release candidate of Windows Package Manager v1.28. If you find any bugs or problems, please help us out by filing an issue.

Release Windows Package Manager 1.28.190 · microsoft/winget-cli