Summary of the new feature / enhancement

When creating a module with cmdlets that contain an unapproved verb the following warning is shown when the module is imported by the user:

WARNING: Some imported command names include unapproved verbs which might make them less discoverable. Use the Verbose parameter for more detail or type Get-Verb to see the list of approved verbs.

There are actually two audiences targeted by the warning:

• The user of the concerned module
• The author of the concerned module

The wording and suggestions in the warning appear to address the author, yet the user is constantly confronted with the warning. Note that the warning doesn't contain the workaround -DisableNameChecking (which shouldn't be used blindly). Quote:

Although the message is displayed to module users, the naming problem should be fixed by the module author.

As the author of the module, there is no clean way (that doesn't violates another a design rule) way to suppress the message knowing that the current implementation is questionable and there are several arguments for allowing exceptions:

in my humble opinion,

• Strongly Encouraged Development Guidelines
  • should be notified at design (development) time (e.g. with thePSSciptAnalyzer) not at run/load time.
  • should be encouraged, not enforced by a reoccurring warning to the user that can't be disabled by the author.
• Common verbs aren't an exact science, quote: "PowerShell uses the System.Management.Automation.VerbsCommon enumeration class to define generic actions that can apply to almost any cmdlet". In fact, there several contradictions and exceptions that make this rule:
  • PowerShell's own violatation for reserved verbs as ForEach and Where
    • Where the Sort verb is probably most questionable
  • forcing approved verbs to an extent that authors are using common verbs as Get and Invoke instead, result in an Invoke-<verb corruption> command name as Get-TopologicalSort (vs. Sort-Topological) or even a well known external cmdlet made less discoverable with a name as Invoke-PSScriptAnalyzer 😵 vs. simply Analyze-Script.
    • Note that the (only?) alternative to using an Invoke-<verb corruption> command name and an unapproved verb alias (to supply a better syntax and make it easier discoverable 🥴) leaves the user of the cmdlet with an avoid using cmdlet aliases best practice issue.
  • "Use the verb to describe the general scope of the action, and use parameters to further refine the action of the cmdlet." In case of a custom cmdlet supports both ways: the action via the verb name and via a parameter (as in my use case where you might use either approved verb with a parameter Join-Object -JoinType Left or the unapproved command LeftJoin-Object), the warning shouldn't apply.

Proposed technical implementation details (optional)

Completely remove the unapproved verbs warning or give the author the ability to disable the unapproved verbs warning in e.g. the modulemanifest either in general (something like: AccepteUnapprovedVerbs = $true) or for specific names (something like: UnapprovedFunctionsToExport = @("function1", "function2", "function3"))

Or being able to override the warning message (something like: UnapprovedVerbWarning = "To sort topological, use the command Sort-Topological.", where an empty string is no warning).

Knowing that the default is still to warn and there are still other means that could trigger author (and the user):

• The Import-Module -Verbose switch:

VERBOSE: The 'LeftJoin-Object' command in the JoinModule' module was imported, but because its name does not include an approved verb, it might be difficult to find. For a list of approved verbs, type Get-Verb.

• The PSScriptAnalyzer to always warn the author during design time.