Flatten the module manifest structure

1-Draft/RFCNNNN-Simplify-Module-Manifests.md

@@ -0,0 +1,170 @@
+---
+RFC: RFCnnnn
+Author: Kirk Munro
+Status: Draft
+SupercededBy: 
+Version: 1.0
+Area: Module Manifests
+Comments Due: July 15, 2019
+Plan to implement: Yes
+---
+
+# Title
+
+When PowerShell module support first came out in PowerShell 2.0, module manifests had a specific list of keys that could be used to define the manifest. Additional keys were added in PowerShell 3.0, but that hurt the end user experience because at the time, if you loaded a module with a manifest containing keys that were not recognized/supported in your version of PowerShell, PowerShell would return an unhelpful error about the module keys being invalid instead of checking for the minimum required version of PowerShell and returning an error indicating that the module only supports that version or later.
+
+Beyond PowerShell 3.0, keys started being added to a PSData subsection of the PrivateData area of modules. You can see these keys in use by the PowerShell Gallery. That approach has its own challenges, because now keys are defined in a hierarchy, which adds complexity and should not be necessary.
+
+Fast forward to today, and things have changed enough that we can reconsider how we set up a module manifest. `Import-Module` has been checking the required version of PowerShell before validating key names for several years now (at least since PowerShell 5.1).  Earlier versions of Windows PowerShell are no longer on mainstream support.
+
+With all of this in mind, I propose that we flatten the module manifest structure, reading values for keys at the root first, and then if they are not set at the root, looking in the PSData section under PrivateData for backwards compatibility support. Future keys added to the manifest as part of PowerShell should all be added to the root, leaving `PrivateData` for 3rd party or user information in a manifest, like it was intended.
+
+## Motivation
+
+    As a scripter,
+    I can generate manifests using `New-ModuleManifest` with all keys stored at the root of the hashtable,
+    so that I can work with module manifests more easily.
+
+## User Experience
+
+Here's an example showing how `New-ModuleManifest` would work after this change:
+
+```powershell
+New-ModuleManifest .\test.psd1 -PassThru | Get-Content
+```
+
+```output
+#
+# Module manifest for module 'test'
+#
+# Generated by: kirka
+#
+# Generated on: 2019-06-09
+#
+
+@{
+
+# Script module or binary module file associated with this manifest.
+# RootModule = ''
+
+# Version number of this module.
+ModuleVersion = '1.0'
+
+# Supported PSEditions
+# CompatiblePSEditions = @()
+
+# ID used to uniquely identify this module
+GUID = '3de89b66-9e70-4f7a-822b-87a8feb94694'
+
+# Author of this module
+Author = 'kirka'
+
+# Company or vendor of this module
+CompanyName = 'Unknown'
+
+# Copyright statement for this module
+Copyright = '(c) 2019 kirka. All rights reserved.'
+
+# Description of the functionality provided by this module
+# Description = ''
+
+# Minimum version of the Windows PowerShell engine required by this module
+# PowerShellVersion = ''
+
+# Name of the Windows PowerShell host required by this module
+# PowerShellHostName = ''
+
+# Minimum version of the Windows PowerShell host required by this module
+# PowerShellHostVersion = ''
+
+# Minimum version of Microsoft .NET Framework required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
+# DotNetFrameworkVersion = ''
+
+# Minimum version of the common language runtime (CLR) required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
+# CLRVersion = ''
+
+# Processor architecture (None, X86, Amd64) required by this module
+# ProcessorArchitecture = ''
+
+# Modules that must be imported into the global environment prior to importing this module
+# RequiredModules = @()
+
+# Assemblies that must be loaded prior to importing this module
+# RequiredAssemblies = @()
+
+# Script files (.ps1) that are run in the caller's environment prior to importing this module.
+# ScriptsToProcess = @()
+
+# Type files (.ps1xml) to be loaded when importing this module
+# TypesToProcess = @()
+
+# Format files (.ps1xml) to be loaded when importing this module
+# FormatsToProcess = @()
+
+# Modules to import as nested modules of the module specified in RootModule/ModuleToProcess
+# NestedModules = @()
+
+# Functions to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no functions to export.
+FunctionsToExport = @()
+
+# Cmdlets to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no cmdlets to export.
+CmdletsToExport = @()
+
+# Variables to export from this module
+VariablesToExport = '*'
+
+# Aliases to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no aliases to export.
+AliasesToExport = @()
+
+# DSC resources to export from this module
+# DscResourcesToExport = @()
+
+# List of all modules packaged with this module
+# ModuleList = @()
+
+# List of all files packaged with this module
+# FileList = @()
+
+# Private data to pass to the module specified in RootModule/ModuleToProcess.
+PrivateData = @{}
+
+# HelpInfo URI of this module
+# HelpInfoURI = ''
+
+# Default prefix for commands exported from this module. Override the default prefix using Import-Module -Prefix.
+# DefaultCommandPrefix = ''
+
+# Tags applied to this module. These help with module discovery in online galleries.
+# Tags = @()
+
+# A URL to the license for this module.
+# LicenseUri = ''
+
+# A URL to the main website for this project.
+# ProjectUri = ''
+
+# A URL to an icon representing this module.
+# IconUri = ''
+
+# ReleaseNotes of this module
+# ReleaseNotes = ''
+
+}
+
+```
+
+## Specification
+
+The changes required for this RFC are relatively straightforward, and as follows:
+
+1. `New-ModuleManifest` would generate a template like what is shown above, omitting any details about the `PSData` section.
+1. Module import logic would read the manifest and pull the values for `Tags`, `LicenseUri`, `ProjectUri`, `IconUri` and `ReleaseNotes` from the top-level keys. If top-level keys were not defined with these values, it would look for values in a `PSData` section for backward compatibility.
+1. If values are defined in both locations, an error would occur informing the module author that they need to remove one of the two keys.
+1. Update `Test-ModuleManifest` to validate the keys in the new locations.
+1. Update `Update-ModuleManifest` to set the keys in the existing location if it is in use, or in the new location otherwise.
+
+## Alternate Proposals and Considerations
+
+### Move `Update-ModuleManifest` from PowerShellGet to Microsoft.PowerShell.Core
+
+This is a question for consideration: why is `Update-ModuleManifest` part of PowerShellGet and not in the Microsoft.PowerShell.Core module? Shouldn't it be co-located with the other `*-ModuleManifest` cmdlets? If so, it could be moved as part of this RFC.