PowerShell / PowerShell/PSScriptAnalyzer

New Rule Request: Warn against module manifests that load their associated script module as a Nested module

Open
#546 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Issue - Discussion
Dominant language
C#
Stars
2.2k
Forks
414
Avg merge
13h 1m
Merged PRs (30d)
2

Description

The Microsoft.PowerShell.Archive module uses a weird way of loading the script module file. Instead of identifying the script module using the RootModule/ModuleToProcess key in the manifest, it uses NestedModules instead. This is unusual, unexpected, and will very likely have side effects. An example of an existing side effect that @jaykul found is:

  • it obscures your module scope, so to inspect the internal variables/state of the module, they can't simply use this technique:

&(gmo Microsoft.PowerShell.Archive) {...}

Instead they have to do this:

&(gmo Microsoft.PowerShell.Archive) {&(gmo Microsoft.PowerShell.Archive) { .... }}

With this approach to module design, there are far more unknowns then there are knowns (can they even access their own metadata, assign an OnClose event handler that works as expected, etc.?).

Regardless of the unknowns, this should be considered an anti-pattern unless (a) there is some benefit to designing modules this way, and (b) there won't be any bugs when designing modules this way.

I recommend creating a rule for modules (once modules are inspected as modules) that warns against this design. It can't really be created until modules are inspected as modules, because it is perfectly valid to create a manifest module that doesn't have an associated script/binary module file and that simply provides a distribution mechanism for multiple modules as a bundle. With that in mind, this should only warn when:

(a) a module manifest defines one or more NestedModules; and
(b) the same manifest does not define RootModule/ModuleToProcess; and
(c) one of the NestedModules is a script or binary module in the same folder as the manifest with the same name.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the module-inspection rules in PSScriptAnalyzer and tracing how manifests and NestedModules are represented. Implement the warning only when all three conditions listed in the issue hold, and add coverage for matching and excluded manifests.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, powershell
Domain
devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.