microsoft
Add aliases to the cmdlets in Microsoft.Winget.Client PowerShell module
Description of the new feature / enhancement
Add some default aliases for commands to reduce typing mistakes and aid use of the module on the cmdline
- [ ] Add-WinGetSource
- [ ] Assert-WinGetPackageManager
- [ ] Disable-WinGetSetting
- [ ] Enable-WinGetSetting
- [ ] Export-WinGetPackage
- [ ] Find-WinGetPackage
- [ ] Get-WinGetPackage
- [ ] Get-WinGetSettings
- [ ] Get-WinGetSource
- [ ] Get-WinGetUserSettings
- [ ] Get-WinGetVersion
- [ ] Install-WinGetPackage
- [ ] Remove-WinGetSource
- [ ] Repair-WinGetPackageManager
- [ ] Reset-WinGetSource
- [ ] Set-WinGetUserSettings
- [ ] Test-WinGetUserSettings
- [ ] Uninstall-WinGetPackage
- [ ] Update-WinGetPackage
Proposed technical implementation details
No response
I frequently find myself typing "find", pressing right arrow to autocomplete Find-WinGetPackage somePackageIdentifier, then pressing Ctrl+backspace to delete the somePackageIdentifier and replace with what I'm looking for. I agree that an alias would be useful, but "find" seems too generic, and also might overlap with find.exe.
Note that PowerShell aliases are typically (but not necessarily) formed based on a naming convention that utilizes a standardized prefix for the verb of the target cmdlet (whereas there are no rules around how to abbreviate the noun part).
E.g., the standardized prefix for the Find verb is fd ((Get-Verb Find).AliasPrefix)
Thus, an alias for Find-WinGetPackage could be fdwg, for instance.
This is a user preference thing not specific to winget. PowerShell uses explicit, verbose cmdlet and parameter names - alwqys. This is good.
If you like cryptic aliases you can always define them yourself in your PowerShell profile:
New-Alias -Alias 'fdwg' Value 'Find-WingetPackage'
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/new-alias?view=powershell-7.4
@jantari: Most of PowerShell's built-in cmdlets have built-in aliases (e.g., gc for Get-Content), and most of these aliases' names are constructed as I've described; the same applies to Microsoft-authored external modules (and many third-party modules).
Let's take the recently introduced Microsoft.PowerShell.PSResourceGet module as an example (which is now bundled with PowerShell 7, installable on demand in Windows PowerShell):
PS> Get-Alias | Where Definition -like '*-PSResource*' | Select Name, Definition
Name Definition
---- ----------
fdres Find-PSResource
isres Install-PSResource
pbres Publish-PSResource
udres Update-PSResource
usres Uninstall-PSResource
Having aliases is important for interactive use, whereas in scripts they should be avoided. PowerShell calls this duality - short alias names, short parameter aliases, the ability to use parameter-name prefixes, positional arguments for interactive convenience vs. the verbose original names and fully named arguments in scripts, for readability and long-term stability - elastic syntax.
While, of course, anyone is free to define their own aliases, having aliases that ship with the module and whose names are methodically constructed is important, as it allows cross-machine use of these aliases without extra effort and facilitates recalling or discovering their names (all it takes is to know the naming convention, and remembering the alias prefixes for the fixed list of approved verbs (some of which are obvious, such as g for Get-)).
This is especially important for cmdlets that are frequently used interactively, as in the case at hand.