Powershell: DefaultCommandPrefix confuses auto-completion and breaks `install-module`

[glatzert]

I'm the maintainer of a small Powershell Module called "ACME-PS", the module uses DefaultCommandPrefix in it's psd1.
This seems to have downsides, and should at least be documented or event "not recommended to use" (or maybe even marked obsolete)

Steps to reproduce

Install-Module ACME-PS # will fail, because missing, but misleading -AllowClobber
Install-Module ACME-PS -AllowClobber

Type "Get-Ord[TAB]" (completes to get-order)
Press [Enter].

Expected behavior

Auto-Completion should not complete to Get-Order, since DefaultCommandPrefix is ACME

Actual behavior

Don't Auto-Complete the command, since it should be "Get-ACMEOr[TAB]" which auto-completes.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[ThomasNieto]

PoweShellGet module is being rewritten and command clobbering is on by default so -AllowClobber will no longer be a parameter, however there are some issues with it. I've open a couple of them when trying to reproduce your issue.

https://github.com/PowerShell/PowerShellGet/issues/204
https://github.com/PowerShell/PowerShellGet/issues/203

Here is a related issue when using DefaultCommandPrefix and module loading: https://github.com/PowerShell/PowerShell/issues/12858

cc: @mklement0

[glatzert]

Do we have any idea, if the problems will be fixed?
I prepared a new module version, which ditches the DefaultCommandPrefix for a static one (as seen in PSDbaTools, e.g.), but I'm unsure, if I want to go down that road or not.

[daxian-dbw]

It looks to me the module analysis code can be improved to take into account the DefaultCommandPrefix setting in .psd1 file.

@ThomasNieto Can you please explain to me why -AllowClobber is required in this case?

[ThomasNieto]

@daxian-dbw I tested with PSGet v3 and -NoClobber command producing these two issues:

PowerShell/PowerShellGet#204
PowerShell/PowerShellGet#203

I was not able to reproduce requiring -AllowClobber in PSGet v2 as the OP indicated. There might be something on the OP system that is causing that.

I did do some tests on PS 5.1 and PS 7.0.3 with PSGet 2.2.4.1. Command conflict checking is working as expected on PS 5.1 but does not properly check on PS 7.0.3. My testing methodology is below:

I tested by checking if there any commands with *acme* prior to install, confirmed there were none, then installed as normal. Then I created a module manifest with FunctionsToExport with a value of Get-Account which is one of the command shipped in acme-ps with default command prefix of acme and still installed as expected.

To test the command conflict I updated the module to have the command Get-AcmeAccount and then installing acme-ps produced the command conflict error only on PS 5.1 but didn't on PS 7.0.3.

The last test was to see if DefaultCommandPrefix was working so I updated the function to Get-Account with a DefaultCommandPrefix of amce, both PS 5.1 and 7.0.3 threw the error as expected.

I know this was a lot but I can put it in a pester test if needed.

[glatzert]

The -AllowClobber message came from the module having Export-(ACME)Certificate clashing with Export-Certificate.
(This also affects Invoke-ScriptAnalyzer as it'll warn about clobbering Export-Certificate.)

Nevertheless I cannot reproduce it again, but I had issues with PowerShellGet, making me remove all modules and clear $env:PSModulePath, so it might really be something on my machine, or an older PSGet Version, which issued that error.

Thanks for your analysis so far 👍