Context: One of our teams has a Chocolatey package that calls Expand-Archive. However, I have the pscx module installed which also provides an Expand-Archive cmdlet whose parameter signature differs from the built-in cmdlet, and causes this package installation to fail. The solution is to use the module-qualified name in case of such an overload. In the end was able to look at the online documentation to get the module name for what it's worth.
Initially, I tried getting the module with:
Get-Command Expand-Archive -All
but this only listed the cmdlet found in the pscx module. It seems that Get-Command -All does not return commands from available modules which have not been loaded yet. This somewhat makes sense for modules which can't be autoloaded but not the built-in ones like Microsoft.PowerShell.Archive, and this is concerning as it leaves me unable to audit the available commands in my session without first loading the module.
Once I load the module with one of the following methods:
Microsoft.PowerShell.Archive\Expand-Archive
Import-Module Microsoft.PowerShell.Archive
Get-Command Expand-Archive -All indeed shows both definitions in the resolved order, and the module they belong to. This is problematic though, because it inhibits my abililty to audit the commands available on my system, short of blindly importing all available modules before running Get-Command (which is a problematic solution in its own right).
The ask: How can I either tell Get-Command to actually retrieve all resolvable commands available to the session, or obtain this information via other means? As modules are auto-imported based on the first usage of one of its functions (something knows the command is in an unloaded module to do the import), I would expect Get-Command should be able to support this.