Support PSModuleInfo as argument to -ModuleName and InModuleScope

[fflaten]

Checklist

• Feature request has a meaningful title
• I have searched the existing issues. See all issues
• I have tested using the latest version of Pester. See Installation and update guide.

Summary of the feature request

Pester currently reference modules by name. This requires modules to be imported and only one instance per name.

At the same time, it blocks us from executing code or injecting mocks inside un-imported dynamic modules and cause some inconsistency with nested modules (see #2234 (comment))

How should it work?

$someNestedModule = (Get-Module ManifestModule).NestedModules[0]
Mock SomeCommand -ModuleName $someNestedModule

[fflaten]

Potential issues with mock history and cleanup in this scenario.
Is there anything identifying a module instances out-of-box? Or would we have to keep a copy of the PSModuleInfo to compare with?

[nohwnd]

If we do allow it, will it be possible for the users to grasp the difference, or is that adding some additional complication to the already complicated world of Mock?

I can see how this could be useful in a rare case where you have a nested module that you are able to access from a different module, and passing on the instance, but is it useful enough in other cases?

Implementing this would possibly mean re-implementing mock searching and history, and maybe breaking some of the current behavior.

What if we simply added a convention like Module|SubModule, and allowed only one level, and inspected NestedModules on behalf of the user? Then maybe all the functionality can remain the same, we will just change the way we resolve the modules.

There currently is some indirect reliance on module instances, e.g. InModuleScope attaches your ScriptBlock to a concrete instance of a module, and if you re-import it, then your module will no longer be the same instance. So in this case it would be easier to detect errors. On the other hand I am not sure if we are relying on the opposite behavior, where the name is universal identifier for any instance of that module, anywhere.

[fflaten]

Thanks for the feedback. Closing for now as cost outweighs reward atm. Can reopen if it becomes a popular request in the future 🙂