Behavior between New-ModuleManifest, Update-ModuleManifest, Test-ModuleManifest is inconsistent

[pougetat]

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.

[iSazonov]

Looks good.

/cc @SteveL-MSFT

[SteveL-MSFT]

One problem I see is that a standard workflow to create a new module is:

new-modulemanifest -path ./foo.psd1 -rootmodule foo.psm1
code foo.psm1

Meaning that they create the manifest before creating the root module script. If New did validation, then this would be breaking. One option would be to add a -Force type switch to allow this, but we could go with a non-breaking change and have a -Validate switch.

[jzabroski]

-Force please. No hacks. Cut the arm off and survive.

[pougetat]

Hey @SteveL-MSFT,
I'm hesitating between -Force and -Validate. On the one hand -Force does seem much more idiomatic than -Validate and it forces the user to think about what the command is doing behind the scenes. The fact that it is a breaking change though does cut down on the appeal.
Can I still go with -Force or should we stick to -Validate ?

[jzabroski]

I vote for -Force

…

On Mon, Apr 1, 2019 at 1:10 PM pougetat ***@***.***> wrote: Hey @SteveL-MSFT <https://github.com/SteveL-MSFT>, I'm hesitating between -Force and -Validate. On the one hand -Force does seem much more idiomatic than -Validate and it forces the user to think about what the command is doing behind the scenes. The fact that it is a breaking change though does cut down on the appeal. Can I still go with -Force or should we stick to -Validate ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbT_eyNjaSrIflImEeH4SNfaAb-2Z-Pks5vcj1zgaJpZM4boyxo> .

[joeyaiello]

The base workflow seems very common to me. Might we be okay with throwing warnings for non-valid values in New-ModuleManifest?

Given the unlikelihood of New-ModuleManifest in fully non-interactive/automated scenarios, this seems like a better approach to me. Are there any automated scenarios I'm not realizing?

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this, we agree that all the checks should be in one place which is Test-ModuleManifest. Continue having Update-ModuleManifest rely on Test-ModuleManifest by default. New-ModuleManifest should have a new -Validate switch that uses Test-ModuleManifest.

[jzabroski]

How is -Validate going to be different from what -Force would do? Does -Validate have side-effects? If so, why call it validate.

[SteveL-MSFT]

@jzabroski the difference is opt-in vs opt-out. We are optimizing for backwards compatibility here so introducing new behavior we decided to have it opt-in so the user needs to explicitly use -Validate. There would not be a -Force which would only be needed for opt-out which we are not supporting for this use case.