-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Ensure NestedModules property gets populated by Test-ModuleManifest #7859
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure NestedModules property gets populated by Test-ModuleManifest #7859
Conversation
|
This seems like the right way to efficiently build/return the nested module info objects. But for the sake of having considered other ideas, wouldn't users expect a fully live nested module info object here? Since the fake module info is the same type that would normally be returned by Further down in the same method when nested modules are read, we actually go and read their manifest and load a module info. Creating fake info objects from the nested module specifications is certainly more efficient, but I think it's a breaking change from previous (pre-regression) behaviour. See Windows PowerShell's version of the same: I think we may be committed to doing the inefficient thing. |
PaulHigin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
|
||
| if (!needToAnalyzeScriptModules) | ||
| { | ||
| // need to add nested modules to the manifestInfo when no more analysis needs to be done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Add nested modules ...
|
@rjmholt You raise a fair point. However, I think most cases the user doesn't need a complete object. In the issue, the problem with the current behavior is that the I would suggest deferring whether we want to add capability to get the entire tree of objects until there is a customer request for it. |
fd861f1 to
6428aaf
Compare
address codefactor issue added test for update-modulemanifest
6428aaf to
36fc6ea
Compare
Maybe use lazy for the objects? |
|
@SteveL-MSFT Thanks for fixing this regression! It looks good to me, but since the same code is used both here and for The helper method can be a iterator method, which can be used for both here an |
|
@daxian-dbw yes, I'll make that change. Thanks! |
daxian-dbw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| } | ||
|
|
||
| /// <summary> | ||
| /// Helper function to generate fake PSModuleInfo objects from ModuleSpecification objects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add final dot.
|
|
||
| BeforeEach { | ||
| $testModulePath = "testdrive:/module/test.psd1" | ||
| New-Item -ItemType Directory -Path testdrive:/module |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please suppress output New-Item -ItemType Directory -Path testdrive:/module > $null.
|
|
||
| BeforeEach { | ||
| $testModulePath = "testdrive:/module/test.psd1" | ||
| New-Item -ItemType Directory -Path testdrive:/module |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same.
| ) { | ||
| param($exportValue) | ||
|
|
||
| New-Item -ItemType File -Path testdrive:/module/foo.psm1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same.
PR Summary
This is a regression introduced by #7145 as an optimization where no further analysis of the module is done if none of the exported capabilities have a wildcard. However, the NestedModules property hasn't been populated yet, so it remains empty. This is a regression as previously this property is always populated if the manifest contains a value.
Fix is to create PSModuleInfo entries for each specified NestedModule even though we don't do actual loading and analysis. Creating the fake NestedModule is similar to how the code already creates fake RequiredModules when not importing.
Also some minor cleanup of repetitive code in the tests.
Fix #7833
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests