[PSS 2015] Primal Sense for modules

Post feature requests, product enhancement ideas, and other product-specific suggestions here. Do not post bug reports.
Forum rules
Do not post any licensing information in this forum.
This topic is 8 years and 3 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked
Bosparan
Posts: 290
Last visit: Fri Oct 08, 2021 11:59 am

[PSS 2015] Primal Sense for modules

Post by Bosparan »

Hi Guys,

when adding an Import-Module statement in a script to another script, PSS will provide primal sense for content contained within. When I do so for a Module, it ... doesn't work out as well.
Or at least, not always.
Imagine a big Module with dozens of scriptfiles in sub-folders (cause writing them all in the same file makes it pretty much unmanageable). Our own best practice is one dedicated file per function, one per other complex resource (eg.: c# Source code compiled at runtime) and one per simple type of resource (eg.: Aliases, Configuration items, ...).

Now, for this to load this properly, we need to Import them within the .psm1-file (the same file we point the original Import-Module at). This is often done like this:
  1. Get-ChildItem "$PSScriptRoot\Functions" | Select-Object -ExpandProperty FullName | ForEach-Object {
  2.     . $_
  3. }
Which has the nice advantage of automatically importing all content you care to add later.
So far so good, PSS is incapable of interpreting this and thus will not provide primal sense for any function contained therein.
It won't recognize direct imports like this either:
  1. . "$PSScriptRoot\Functions\Get-Test.ps1"
I'd like for PSS to be able to provide Primal Sense for script modules more efficiently, so those too will benefit from the powerful help Primal Sense provides.

Ideas on how to realize this:

1) Parse and interprete
Going the hard way, interpreting the PSScriptRoot variable (and the various other ways to determine the current modulepath), then scanning it and loading all nested imports (including the parsing of get-childitem calls) to obtain a full list of imports.

Disadvantages
- Heavy effort to implement the feature
- Error-Prone

Advantages
+ Intuitive for the scripter
+ Usable on all Script-Modules, past and present

2) Information comments
Agree on a syntax how developers can communicate to PSS which files to load and interprete for Primal Sense purposes.
For example by placing a comment in the .psm1 file:
  1. #import "Functions\*.ps1"
Disadvantages
- Not intuitive for scripters
- Not automatically included in already existing modules

Advantages
+ Simple to implement the feature
+ Reliable for the scripter (Behavior is absolutely predictable)
+ Great control what primal sense is provided for

3) Exported Commands
A third solution is to scan all files in the module folder (+ Subfolders), but only provide Primal Sense for functions that are listed as exported commands (when using Get-Module -ListAvailable, interpreting the modulepath as in one of the $env:PSModulePath paths).

Disadvantages
- Will only work on modules that properly mark their functions as exported (= Will not work on quite a few modules)

Advantages
+ Furthers good coding practices
+ Simple to implement the feature
+ Automatically includes changes


All said, I'd prefer option three ... anything that reinforces good habits.

Cheers,
Bosparan
User avatar
davidc
Posts: 5913
Last visit: Mon Jul 08, 2019 8:55 am
Been upvoted: 2 times

Re: [PSS 2015] Primal Sense for modules

Post by davidc »

Once again, thank you for your feedback. I will pass these points along to the team.

David
David
SAPIEN Technologies, Inc.
This topic is 8 years and 3 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked