Extend Export-ModuleMember to Support Enums, Classes, Interfaces, and DSC Resources

[michaeltlombardi]

As a PowerShell module author and maintainer, I want to be able to export enums, classes, interfaces, and DSC Resources from my module to the caller's scope without requiring them to call the using statement. I also want to be able to limit these items exported from my module with the *ToExport key in my module manifest as I do with functions, aliases, and variables.

As a user, I expect that a module's exported enums, classes, interfaces, and DSC Resources are namespaced to that module; i.e. Import-Module Foo which exports the Bar enum would enable me to immediately call [Foo.Bar] and see the type information. To maintain backwards compatibility, I would expect to be able to call using module Foo to load any unexported enums.

Currently, for a user to take advantage of enums or classes defined in a PowerShell module, they need to:

1. Know that the type exists
2. Call using module <module name> to load all of the types from that module

Alternatively, the module author can add a script in the ScriptsToProcess key of their module manifest which specifies the using statement for them.

For types which are included in a module and not meant to be exported, this is a reasonable UX - the user has to opt in to use a component not intended for direct/common consumption (but also not prevented from doing so - though there's no way to implement private classes or enums in PowerShell today). However, as a module author, if I want to export a type for my users, the only way to do so is with the ScriptsToProcess workaround.

Further, this would help move DSC Resource discovery from a special case towards a normal exported member of a PowerShell module.

Proposal

I propose that the Export-ModuleMember cmdlet be extended to support enums, classes (and by extension, DSC Resources), and (if #83 is implemented) interfaces. Ideally, this would come along with the ability to unload these types when the module is removed.

Optionally, this import behavior would require an opt-in switch parameter on Import-Module like LoadTypes - this is probably necessary if unloading is not feasible or implemented.