Flatten the module manifest structure

[KirkMunro]

No description provided.

[KirkMunro]

@SteveL-MSFT FYI, when you get to it, since you own PowerShellGet now one part of this RFC that I'd specifically like your feedback on is the alternate proposal section about the module where Update-ModuleManifest lives.

[SteveL-MSFT]

@KirkMunro The main issue with this proposal is that it makes modules using this format only compatible with PS7 and newer. If we think that is acceptable, it may make sense to just calls this psd2. It doesn't seem like the benefits outweigh the compatibility cost, however.

[KirkMunro]

That's been the longstanding argument against this type of update in the past. While I've always felt that to be a lame argument, consider this:

1. Recent PowerShell versions check the required PowerShellVersion value of a manifest first, before looking at anything else, so there's no issue there.
2. Only manifests created using New-ModuleManifest in PowerShell 7 would have this format, not others, so the requirement is only an issue if you're using New-ModuleManifest in PowerShell 7 to create PowerShell modules for older versions.

As for benefit vs cost, there are open RFCs which would result in additional manifest keys added to a module manifest. What then? Are we stuck putting all new keys in PSData until the end of PowerShell because of a design issue that was identified but not fixed years ago (in the PowerShell 3 timeframe)?

Here's an intriguing thought @SteveL-MSFT: New-ModuleManifest has a -PowerShellVersion parameter. Currently there is no default value for that parameter, and the manifests are created with the PowerShellVersion commented out. What if we made -PowerShellVersion always have a default value of the current version of PowerShell, generating an appropriate manifest for that version. We shouldn't have to go downlevel very far (although it wouldn't be difficult to go back all the way to v2), and it would enable the creation of manifests for modules supporting older versions on newer versions of PowerShell. There could also be a comment above the PowerShellVersion suggesting if you change it to an earlier version, you may need to manually update other parts of the manifest to make it compatible. That approach keeps psd1 as the extension name and enables forward thinking/progression while respecting people using newer OSes/versions of PowerShell to design/develop for downlevel versions.

[iSazonov]

We could add -BackwardCompatible parameter to generate manifests in 3.0 format.

[KirkMunro]

@iSazonov Added as an alternate proposal. My concern with that approach is what happens if we add one or more keys in 7, and then others in 7.x or in 8 or some other version. How would you generate a manifest for the appropriate version then?

[ThomasNieto]

Here is an example of adding a new module manifest key for CompatibleOS in PowerShell/PowerShell#9784. There needs to be a way to add new module manifest keys to leverage new features and still being able to import that module on earlier PS versions. CompatiblePSEditions was the first time a manifest key was added and most module authors don't use it since it limits module compatibility to PS 5.1+.

[KirkMunro]

With PowerShell 7 installing side-by-side with Windows PowerShell, I'm very curious to see how backwards compatibility concerns will evolve (and hopefully diminish greatly).

[joeyaiello]

My personal take is that the bar for reformatting the module manifest in a way that breaks back-compat with 5.1 should still be very, very high. Backwards compatibility is a huge tenet of what we're trying to do in 7, and even with a -BackwardsCompatible switch, we're still breaking that in the default case.

To that end, I'm not sure exactly what we're gaining here other than "the module manifest looks nicer". It does absolutely look nicer, and I agree that the current state of module manifests has gotten cluttered from ad-hoc additions, but we have New-ModuleManifest and Update-ModuleManifest generating pretty well-commented boilerplate. (And where it's not well-commented, we should fix that, like in PSData.)

As for the philosophy on adding new manifest keys in the future, I don't know that it would change just because we came up with a new schema here. Personally, I was in favor of changing future versions of PS to loosely validate the module manifest so that we could one day treat the whole thing like PSData, but consensus won out to maintain the current behavior. (I remember the rationale being something along the lines of "whatever it is, it likely won't be a required feature, and if you want the feature, it won't work downlevel if you're specifying it", but I'm probably representing it wrong.)

That being said, I think it's worth us reviewing a few of those RFCs proposing additions before making a call here.

[KirkMunro]

Thanks for sharing your thoughts on this @joeyaiello.

One more point for consideration as you guys keep reviewing the current crop of RFCs:

As a module author, if I'm on PowerShell 7 and I create a new module using that version, with the manifest configured by default to work with (m)any downlevel versions of PowerShell, but I'm not thinking about that or testing those versions, is that the right thing to do? i.e. By deferring the thought process of the minimum version of PowerShell you want to support in a module, are we helping folks because hey, it's just scripting, and so everything should work, right? Or are we hurting folks because users may download a module that was never designed for use, nor tested, with a certain version of PowerShell, and therefore it may very well not work with that version, but the author may not have been paying enough attention to set up the minimum version.

By creating module manifests for a specific version, and forcing the choice on the module author to specify the version they want to support as their minimum (since it would default to the current version of PowerShell), we're properly identifying whatever minimum bar the module author wants while also opening the door to easier manifest additions going forward.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this, we believe this is too big a change and not providing sufficient value.

The significant majority of module authors would want the largest addressable market which would mean not using a module manifest format that is incompatible with at least 5.1. So the utility of this change is minimal.

We agree that there should be consistency going forward on PowerShell Team extensions to the module manifest within PSData. We have opened an issue to have discussion on new items that should be added to PSData. We would encourage you to add your suggestions to that issue.