Powershell: (PowerShell 7) Get-Module exposes PreRelease without exposing PreRelease

[corbob]

Steps to reproduce

Get-Module PSReadLine
# Note output includes a PreRelease property
Get-Module PSReadLine | select *
# Note output does not include a PreRelease property

Expected behavior

(note: I removed the majority of properties to focus on the missing property PreRelease)

C:\Users\corbob> get-module psreadline

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Script     2.0.0      beta5      PSReadLine                          {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PSReadLineKeyHandler, Set-PSReadLineKeyHandler…}

C:\Users\corbob> get-module psreadline | select *

LogPipelineExecutionDetails : False
Name                        : PSReadLine
Path                        : C:\program files\powershell\7-preview\Modules\PSReadLine\PSReadLine.psm1
# a bunch of properties removed for brevity
Version                     : 2.0.0
PreRelease                : beta5

Actual behavior

(note: the only thing I removed from this output was the signature block because it was just a wall of text that adds nothing in this context)

C:\Users\corbob> get-module psreadline

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Script     2.0.0      beta5      PSReadLine                          {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PSReadLineKeyHandler, Set-PSReadLineKeyHandler…}

C:\Users\corbob> get-module psreadline | select *

LogPipelineExecutionDetails : False
Name                        : PSReadLine
Path                        : C:\program files\powershell\7-preview\Modules\PSReadLine\PSReadLine.psm1
ImplementingAssembly        :
Definition                  : function PSConsoleHostReadLine
                              {
                                  Microsoft.PowerShell.Core\Set-StrictMode -Off
                                  [Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
                              }


                              # SIG # Begin signature block
                              # Signature block removed for brevity

Description                 : Great command line editing in the PowerShell console host
Guid                        : 5714753b-2afd-4492-a5fd-01d9e2cff8b5
HelpInfoUri                 : https://go.microsoft.com/fwlink/?LinkId=528806
ModuleBase                  : C:\program files\powershell\7-preview\Modules\PSReadLine
PrivateData                 : {PSData}
ExperimentalFeatures        : {}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    :
Version                     : 2.0.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0.0
CompanyName                 : Microsoft Corporation
Copyright                   : (c) Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      : 4.6.1
ExportedFunctions           : {[PSConsoleHostReadLine, PSConsoleHostReadLine]}
Prefix                      :
ExportedCmdlets             : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption, Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler], [Set-PSReadLineKeyHandler,
                              Set-PSReadLineKeyHandler]…}
ExportedCommands            : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption, Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler], [Set-PSReadLineKeyHandler,
                              Set-PSReadLineKeyHandler]…}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {Microsoft.PowerShell.PSReadLine2}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : PSReadLine.psm1
ExportedVariables           : {}
ExportedAliases             : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {C:\program files\powershell\7-preview\Modules\PSReadLine\PSReadLine.format.ps1xml}
ExportedTypeFiles           : {}

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.4
PSEdition                      Core
GitCommitId                    7.0.0-preview.4
OS                             Microsoft Windows 10.0.19002
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[vexx32]

It looks like the formatter is pulling the prerelease information from PrivateData.PSData.Prerelease

We could potentially have this information added as an ETS property for any modules that have prerelease version information, so that it's not a property seemingly coming from thin air on the objects being output.

[SteveL-MSFT]

@vexx32 is correct, the table format presents what is a nested property. Since the data is there in the object (just nested several levels deep), I don't know if we want to replicate it with ETS. The intent with the table format is to easily see what prerelease you are using and expect automation to use the existing nested member.

[vexx32]

That's assuming you know the nested member is there at all. Is PrivateData's structure enforced at all? I've seen a fair few odd things squirreled away there, and it's just a hashtable really, so unless you already know where it is (i.e., it's well-documented in an appropriate place), I don't think we should expect users to know exactly where to find prerelease data.

Of course, this would be a non-issue if module manifests just supported SemVer properly, but we've had the SemVer talk pretty recently - #2983 was recently resurfaced and we're still waiting on the CoreFX team to get that sorted, really.

Also, I tend to dislike the formatter showing properties that "aren't really there" or are buried several levels deep, unless it's just rendering the data that _is_ there in a way that is really only useful for formatting. If we're showing it off, it should be reasonably readily accessible, not 3 levels deep -- in my opinion. 🙂

[SteveL-MSFT]

PrivateData exists specifically because the structure is not enforced. Currently, psd1 files are strictly validated with the exception of PrivateData. This enables backwards compatibility. I think we should seriously consider making psd1 loosely validated so we can add actual new members without worry about breaking compat. However, that also means that it only works with that version going forward (modules authors may not like limiting their audience so adoption of such a thing would be low until most users move to that version of PS).

There are already many cases where formatting shows "phantom properties" or renames properties to make them better viewed on the console, but the actual property name is something else. One thing we could do is have some formatting to make those members more obvious that they aren't actually part of the object.

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.