Skip to content

Commit d109692

Browse files
KirkMunroKirkMunro
committed
first draft
1 parent 65cdf61 commit d109692

File tree

1 file changed

+170
-0
lines changed

1 file changed

+170
-0
lines changed

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

Lines changed: 170 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,170 @@
1+
---
2+
RFC: RFCnnnn
3+
Author: Kirk Munro
4+
Status: Draft
5+
SupercededBy:
6+
Version: 1.0
7+
Area: Module Manifests
8+
Comments Due: July 15, 2019
9+
Plan to implement: Yes
10+
---
11+
12+
# Title
13+
14+
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.
15+
16+
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.
17+
18+
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.
19+
20+
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.
21+
22+
## Motivation
23+
24+
As a scripter,
25+
I can generate manifests using `New-ModuleManifest` with all keys stored at the root of the hashtable,
26+
so that I can work with module manifests more easily.
27+
28+
## User Experience
29+
30+
Here's an example showing how `New-ModuleManifest` would work after this change:
31+
32+
```powershell
33+
New-ModuleManifest .\test.psd1 -PassThru | Get-Content
34+
```
35+
36+
```output
37+
#
38+
# Module manifest for module 'test'
39+
#
40+
# Generated by: kirka
41+
#
42+
# Generated on: 2019-06-09
43+
#
44+
45+
@{
46+
47+
# Script module or binary module file associated with this manifest.
48+
# RootModule = ''
49+
50+
# Version number of this module.
51+
ModuleVersion = '1.0'
52+
53+
# Supported PSEditions
54+
# CompatiblePSEditions = @()
55+
56+
# ID used to uniquely identify this module
57+
GUID = '3de89b66-9e70-4f7a-822b-87a8feb94694'
58+
59+
# Author of this module
60+
Author = 'kirka'
61+
62+
# Company or vendor of this module
63+
CompanyName = 'Unknown'
64+
65+
# Copyright statement for this module
66+
Copyright = '(c) 2019 kirka. All rights reserved.'
67+
68+
# Description of the functionality provided by this module
69+
# Description = ''
70+
71+
# Minimum version of the Windows PowerShell engine required by this module
72+
# PowerShellVersion = ''
73+
74+
# Name of the Windows PowerShell host required by this module
75+
# PowerShellHostName = ''
76+
77+
# Minimum version of the Windows PowerShell host required by this module
78+
# PowerShellHostVersion = ''
79+
80+
# Minimum version of Microsoft .NET Framework required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
81+
# DotNetFrameworkVersion = ''
82+
83+
# Minimum version of the common language runtime (CLR) required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
84+
# CLRVersion = ''
85+
86+
# Processor architecture (None, X86, Amd64) required by this module
87+
# ProcessorArchitecture = ''
88+
89+
# Modules that must be imported into the global environment prior to importing this module
90+
# RequiredModules = @()
91+
92+
# Assemblies that must be loaded prior to importing this module
93+
# RequiredAssemblies = @()
94+
95+
# Script files (.ps1) that are run in the caller's environment prior to importing this module.
96+
# ScriptsToProcess = @()
97+
98+
# Type files (.ps1xml) to be loaded when importing this module
99+
# TypesToProcess = @()
100+
101+
# Format files (.ps1xml) to be loaded when importing this module
102+
# FormatsToProcess = @()
103+
104+
# Modules to import as nested modules of the module specified in RootModule/ModuleToProcess
105+
# NestedModules = @()
106+
107+
# 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.
108+
FunctionsToExport = @()
109+
110+
# 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.
111+
CmdletsToExport = @()
112+
113+
# Variables to export from this module
114+
VariablesToExport = '*'
115+
116+
# 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.
117+
AliasesToExport = @()
118+
119+
# DSC resources to export from this module
120+
# DscResourcesToExport = @()
121+
122+
# List of all modules packaged with this module
123+
# ModuleList = @()
124+
125+
# List of all files packaged with this module
126+
# FileList = @()
127+
128+
# Private data to pass to the module specified in RootModule/ModuleToProcess.
129+
PrivateData = @{}
130+
131+
# HelpInfo URI of this module
132+
# HelpInfoURI = ''
133+
134+
# Default prefix for commands exported from this module. Override the default prefix using Import-Module -Prefix.
135+
# DefaultCommandPrefix = ''
136+
137+
# Tags applied to this module. These help with module discovery in online galleries.
138+
# Tags = @()
139+
140+
# A URL to the license for this module.
141+
# LicenseUri = ''
142+
143+
# A URL to the main website for this project.
144+
# ProjectUri = ''
145+
146+
# A URL to an icon representing this module.
147+
# IconUri = ''
148+
149+
# ReleaseNotes of this module
150+
# ReleaseNotes = ''
151+
152+
}
153+
154+
```
155+
156+
## Specification
157+
158+
The changes required for this RFC are relatively straightforward, and as follows:
159+
160+
1. `New-ModuleManifest` would generate a template like what is shown above, omitting any details about the `PSData` section.
161+
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.
162+
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.
163+
1. Update `Test-ModuleManifest` to validate the keys in the new locations.
164+
1. Update `Update-ModuleManifest` to set the keys in the existing location if it is in use, or in the new location otherwise.
165+
166+
## Alternate Proposals and Considerations
167+
168+
### Move `Update-ModuleManifest` from PowerShellGet to Microsoft.PowerShell.Core
169+
170+
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.

0 commit comments

Comments
 (0)