Helper functions in modules

This topic contains 3 replies, has 2 voices, and was last updated by Profile photo of Poshoholic Poshoholic 3 years, 9 months ago.

  • Author
    Posts
  • #8374
    Profile photo of Matt Tilford
    Matt Tilford
    Participant

    I was wondering what the preferred method of hiding helper functions in a module. My module is applying a set of ACL permissions across 2 levels of a folder template with the second (helper) being called to handle the subfolders. I don't want people to see the second function because it's not meant to be called on it's own.

    I've seen a few suggestions on how to accomplish this.

    1) Give the helper function a non verb-noun name (or at least an invalid verb name) which would cause the function to be hidden from a normal call of import-module.

    2) Use Export-ModuleMember at the bottom of the module for each function i do want to export.

    3) Build a module manifest to list the functions i want to export.

    I'm leaning towards 3 because it's the one i heard about through CBT Nuggets but also because it seems to be the "right" way to do it and has more options to add for the module.

    What is the best practice?

    Also as i am not exposing the function do i need to worry about adding comment based help? You won't be able to view it without opening up the module.

  • #8375
    Profile photo of Poshoholic
    Poshoholic
    Member

    Personally I do both 2 and 3. 3 allows commands to be discovered automatically using PowerShell without loading the module (although it can do that on its own as well, but it's not fool-proof), and 2 allows you to define which functions get exported.

    Also, for internal functions, I wouldn't bother with comment-based help...that's not necessary. Just add comments if there is anything complicated or anything that isn't very intuitive so that you or someone else can figure them out later.

  • #8376
    Profile photo of Matt Tilford
    Matt Tilford
    Participant

    [quote=8375]Personally I do both 2 and 3. 3 allows commands to be discovered automatically using PowerShell without loading the module (although it can do that on its own as well, but it’s not fool-proof), and 2 allows you to define which functions get exported.
    [/quote]

    Is there a particular reason that you use 2 to define the functions instead of the FunctionsToExport on the manifest? I'm just making sure i find my feet correctly as i take my first steps into this. My old scripts are responsible for enough puppy deaths from a lack of asking questions beforehand.

  • #8382
    Profile photo of Poshoholic
    Poshoholic
    Member

    I don't do 2 instead of 3, I do 2 and 3. Here's my general module creation method:

    1. Create the PSM1 file, add Set-StrictMode -Version 2 (or Latest if I'm not using WMI amended qualifiers, which have a bug with strict mode -v 2), and add Export-ModuleMember with no parameters.
    2. Add my functions to the module, and since they are not exported by default, add Export-ModuleMember calls where appropriate for functions and aliases. Since I need to explicitly export aliases anyway, explicit exportation is the way to go for me.
    3. Before I publish my module, once all looks good, I get the list of exported commands (Get-Command -Module MyModule) and then copy that into the FunctionsToExport section of my PSD1 file.

    The only challenge at this point is that I now have to maintain FunctionsToExport when I add additional functions as I iterate over time because now the module will only export what is on the FunctionsToExport list, but I'm ok with that.

    There may be some better alternatives to this, but it is the approach I have been practicing for a while now.

You must be logged in to reply to this topic.