dsccommunity
CommonResourceHelper.psm1: Consider Importing via NestedModules in xPSDesiredStateConfiguration.psd1
CommonResourceHelper.psm1 is currently loaded individually in each resource via Import-Module. We should consider having this loaded via the NestedModules property in xPSDesiredStateConfiguration.psd1 instead.
If the modules are put in nested modules the helper functions should not be exported, and they might be exported into the user session by default. I don’t think it’s good practice to export help functions into the user session, and that could lead to very strange problems if the wrong helper function would be used when using several resources that uses the same method. The reason xEchange work is because so far no other resource do this, but as soon a user uses resources from two modules that exports the internal helper functions, the problem will occur eventually. I just think using nested modules is not worth the risk having a problem down the road.
Currently the PSD1 doesn't limit the number of cmdlets to export because CmdletsToExport = '*'is used. Could it be feasible to add the required *-TragetResource cmdlets from the resources to CmdletsToExport which then should effectively prevent the export of helper functions into the user session.
Maybe, yeah. Because resources are found without the need for Export-ModuleMember or anything in the .psd1 file. So maybe just making it an empty @() might work.
It should be easily tested by importing the module and see if it does now view the helper functions once the modules are put into the neatedmodule property. :thinking:
Hmmmm ... What I initially meant was adding the *-TargetResource functions for every resource into CmdletsToExport in the PSD1 file and import the common helper module as proposed by @mhendric by using the NestedModules. As far as I understood PSD1 CmdletsToExport and Export-ModuleMember , the CmdletsToExport has precedence. So this should filter all (unwanted) exports from submodule. Am I wrong about this? But I agree with you, this could be tested pretty easy :-D
Interesting discussion about this (precedence of CmdletsToExport and Export-ModuleMember) in the PSScriptAnalyzer repo :-D
https://github.com/PowerShell/PSScriptAnalyzer/issues/434
Especially this statement
https://github.com/PowerShell/PSScriptAnalyzer/issues/434#issuecomment-178151123
Perhaps we can then create a PSScriptAnalyzer rule that tests if a all *-TargetResource of the resources are present in the PSD1 of the DSC Module. As I mentioned before this (should) prevent cluttering up the Powershell session scope when a DSC Module is imported.
The resource functions *-TargetResource does not need to be in the psd1-file, nor in the Export-ModuleMember cmdlet. When running Get-DscResource it does not use the psd1-file, nor the Export-ModuleMember. It scans the $env:PSModulePath's folders for resources (don't know the exact process here).
So I think we only need to make sure the internal functions are not exported to the (user) session.