Powershell Module Design - Export-ModuleMember

Question

I am building a module that exports a cmdlet that I would like to make available through my profile. The implementation of this cmdlet is spread across multiple implementation files that contain implementation functions I don't want to make publicly available. So I use Export-ModuleMember to hide them.

get_something.psm1

import-module .\get_something_impl.psm1

function Get-Something {
    [cmdletbinding()]
    Get-SomethingImplementation
}

Export-ModuleMember -Function Get-Something

I then add get_something.psm1 to my profile. By exporting only Get-Something all of my implementation functions remain "private".

The issue I'm experiencing is that when using the Export-ModuleMember command, I have to import a module in my implementation files every time I need a function inside of it. For example, assume I have a module person.psm1 with a function Get-Person that I need to call throughout all of my implementation files. Now I must import person.psm1 in every single file that I need to call Get-Person. This is a result of using Export-ModuleMember -Function Get-Something. Without it, I would only need to import person.psm1 once and it would be available.

In essence, Export-ModuleMember is not only blocking my implementation to the outside, it's blocking it from my own implementation.

Is this expected and considered a normal aspect of designing Powershell modules?

Answer 1

This was actually a bit of debate during the development of modules. Originally, Export-ModuleMember was required to export any function. This became tedious and limiting. So, by default, all functions from a module are visible, but variables and aliases are not, as long as you've never used Export-ModuleMember within the .PSM1.

If you use Export-ModuleMember, it begins to restrict that list. It may not be a bad idea to export a smaller number of functions, but you have to use it somewhat carefully.

You can either write:

Export-ModuleMember -Function a,b,c

which exports a few functions.

or

Export-ModuleMember -Function *

The latter one is equivalent to omitting Export-ModuleMember altogether.

You can use more restrictive wildcards if you'd like, but I find that 99% of the time, you don't need to bother with it at all.

The other thing you seem to be asking is how best to handle module dependencies. Nowadays, it's fairly common to import a module or two when writing a script, just like it's fairly common to include an assembly or two in a C# project. If you're doing this inside of a module, you can use the -Global flag on Import-Module, and avoid using -Force (which will reload the module). This makes it a notch more efficient to reuse the module in different functions. It also makes it less likely to have problems with "cycling" (unloading and reloading) the module, which, unfortunately, many modules do not do well.

The alternative to referencing the module in each function is using a module manifest (Get-Help New-ModuleManifest). Module manifests are very interesting, and required learning for many parts of module development. If you include a module in the RequiredModules list of the Module manifest, it will be automatically loaded before the module is imported (at least in PowerShell 3 and greater). If you include a module in the NestedModules list of the module manifest, it will be loaded as part of the module, and the commands exported by the module will be exported by your module instead.

Module design is a tricky beast, but it's very rewarding to do right. Best of luck.