Clean up stream messaging in Import-Module (specifically in ModuleCmdletBase)

Summary of the new feature/enhancement

Import-Module is an example of how not to use streams in PowerShell. If the Verbose stream is not silenced with S.M.A.ActionPreference.SilentlyContinue or S.M.A.AP.Ignore, Import-Module outputs a ton of useless information to the Verbose stream. This does nothing more than create noise, and causes problems for anyone wanting to turn on verbose stream output to get to the bottom of real problems.

As a scripter, I want to see Progress messages for any stream output that is intended to show progress of a command, so that I don’t have progress messages cluttering up my log files.

As a scripter, I only want to see Verbose messages if they will help me troubleshoot a command that I invoked, so that I can get to the bottom of issues quickly without reading reams of irrelevant log messages.

As a command author, I only want to see Debug messages if they will help me diagnose why a command may be failing without using the debugger, so that I can get to the bottom of issues quickly without reading reams of irrelevant log messages.

Those three problem statements may not all apply here, but I wanted to call them out because the streams need to be used with intent, not just chosen arbitrarily to communicate some text message.

Proposed technical implementation details (optional)

Evaluate each of the Cmdlet.Write* invocations in https://github.com/PowerShell/PowerShell/blob/8f37cced709168f313a00b2e3ee7088495bbcd7a/src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs, and determine which stream should be used for each of the messages based on their intent, removing any messages that add no value whatsoever.

[mklement0]

@vexx32, for Export-ModuleMember calls this is to be expected: they execute in PowerShell code that acts on $VerbosePreference set to Continue (either via an ancestral variable or via -Verbose); note that the messages are Export-ModuleMember’s, not Import-Module’s.

As such, this is simply another manifestation of the dynamic scoping problem discussed above, and something the workaround would eliminate.

[SeeminglyScience]

Okay so auto loading itself doesn’t trigger it, it’s the same preference propagation problem. The module I was testing with had logic in the psm1 to Import-Module a dll.

So technically it’s not triggering during auto load, but if you auto load a script module it looks like it anyway.