Description
Summary of the new feature/enhancement
The behavior between New-ModuleManifest, Update-ModuleManifest and Test-ModuleManifest seems inconsistent.
-
New-ModuleManifest does not check whether or not the values entered by a user are correct. This means that a user can create an invalid manifest file using this cmdlet on which Test-ModuleManifest will fail.
-
Update-ModuleManifest uses Test-ModuleManifest to check certain fields in the manifest file that the user is updating. These values are not necessarily values passed to Update-ModuleManifest but rather values which are already present in the manifest file. Update-ModuleManifest also adds some extra checks that Test-ModuleManifest does not do (ex : ExternalModuleDependencies need to be present under RequiredModules or NestedModules)
-
Test-ModuleManifest does not check the Private data section at all.
Proposed technical implementation details (optional)
-
Test-ModuleManifest should include all checks currently in this cmdlet and in Update-ModuleManifest that are not present in Test-ModuleManifest. This would allow us to remove a lot of extra checks present in Update-ModuleManifest (PowerShellGet issue but still important to mention here)
-
Update-ModuleManifest solely relies on Test-ModuleManifest for its checks.
-
New-ModuleManifest uses Test-ModuleManifest to check for invalid values. This would be a breaking change since users would no longer be able to create invalid manifest files via this cmdlet. However I think it would be a minor breaking change since it's hard to see the use case for automating the creation of manifest files.