PowerShell 7.1 Team Investments and Preview.1 Release

The PowerShell 7 release marks a huge milestone for PowerShell, the community, and the team!

Today we released the first preview for PowerShell 7.1! This release includes a number of changes that did not make it in time for the 7.0 release. It also includes .NET 5 preview 1!

The PowerShell team is not resting on our laurels and are committed to continuous improvement of PowerShell as we plan out our 7.1 release. This blog post details the areas of investment that the PowerShell team is funding. As we’ve done in the past, we’ll also be working with contributors interested in implementing new features as part of the 7.1 release.

Release Cycle Changes

PowerShell Core 6.0 through PowerShell 7 was on a (roughly) 6 month release cadence.

Starting with PowerShell 7.0, we shifted to align with .NET’s release and support life-cycle more closely. This means we intend to ship 7.1 within a week or two of .NET 5’s release date of winter 2020 and align with their annual release cadence going forward.

Modules and Tooling for the 7.1 Release Time Frame

Not everything here is expected to ship with PowerShell 7.1, but the work is being done along with PowerShell 7.1 development.

PowerShellGet 3.0

At the beginning of PowerShell 7 development, we announced PowerShellGet 3.0. This is a complete rewrite of PowerShellGet covering 3 big areas:

• Improving the user experience
• Removing dependency on PackageManagement (and Nuget provider) making the codebase simpler and easier to maintain
• Moving from PowerShell script to C# making it easier to maintain a large and complex codebase

Based on community feedback, we wanted to take an opportunity to address many of the user experience shortcomings with a major release that will have breaking changes. We also want to leverage learnings from popular package managers like apt (on Linux) to adopt conventions already used and proven by a large set of users.

PowerShellGet 3.0 will ship on PowerShell Gallery initially, with tentative plans to deliver it into PowerShell 7.x side-by-side with PowerShellGet 2.0.

The first preview is expected later this month!

Secret Management Module

We are still working on completing Secret Management module, specifically adding Linux support, possibly macOS support, and continuing to address user feedback.

We received lots of good feedback from our preview 1 release which helped shape our preview 2 release. Thanks so much and it shows that getting previews out early really helps the project!

This module is shipped via PowerShell Gallery supporting Windows PowerShell 5.1 and PowerShell 7 and potentially included by default with PowerShell 7.1. This module enables secure storage and retrieval of secrets locally as well as using extensions to store and retrieve secrets from remote vaults (like Azure Key Vault).

We are also working with partners to have vault extensions available soon!

VSCode-PowerShell, PSEditorServices, and PSScriptAnalyzer 2.0

The PowerShell extension for Visual Studio Code and PowerShell Editor Services rely on PSScriptAnalyzer to perform real-time linting as you author or edit a PowerShell script. However, this scenario was not part of the original intent nor design of PSScriptAnalyzer and thus has become a user experience where errors and corrections lag after the user input. Major portions of PSScriptAnalyzer needs to be updated or rewritten to significantly improve throughput to make the interactive user experience more instantaneous, delightful, and productive.

PowerShell Jupyter Kernel

Jupyter notebooks are gaining popularity as a way to have executable code and text content in the same document. There have been existing Jupyter kernels available that support PowerShell, however, we wanted to invest in this space with one that would be supported by the PowerShell team and providing a complete experience.

We’ve already shipped the first preview of our PowerShell sub-kernel that is part of the DotNet Interactive Jupyter kernel.

We will coontinue to improve this experience making it a great choice for PowerShell and Jupyter users.

platyPS vNext

PlatyPS is a PowerShell module that we currently use to convert PowerShell documentation from markdown to updatable-help and is available via PowerShell Gallery. Based on feedback from content authors and partner teams, we need to invest in this tool to improve the author experience as well as improving capabilities of our documentation. This will be a rewrite to support improved Markdown parsing, rendering, and fulfilling requirements for our internal pipelines to publish updateable help.

Themes for PowerShell 7.1

Installation and Updating

A major pain point for our customers, particularly on Windows, is that installing and updating PowerShell 7 requires too many manual steps. We are exploring some options to make it easier to install as well as keep PowerShell updated. At this time, we still do not have a plan to ship PowerShell 7 in Windows due to differences in support requirements that we are still working through.

Shell Improvements

Most native commands work just fine from within PowerShell, however, there are some cases where the argument parsing is not ideal (like handling quotes properly). The intent is to enable users to cut sample command lines for any popular native tool, paste it into PowerShell, and it just works without needing PowerShell specific escaping.

In addition, for advanced users that want to mix PowerShell specific concepts with native commands, things may not work as expected. For example, PSDrives are a great way to abstract a file path across operating systems, but only PowerShell cmdlets and scripts can use them. We want to explore how to expose these things to native commands.

Interactive User Experience

To enable users to be more productive at the shell, we want to enable two new scenarios:

• Enable predictions: We are investigating how the community can author different prediction engines helping the user complete a pipeline with minimal typing.
• Enable dynamic help: While authoring a pipeline in the console, the user should be able to get context aware help like presenting help on parameters as they are typing or get full help content without having to abandon their current input or open a new console.
• Enable use of color: We added some additional use of color in PowerShell 7.0 to provide visual cues when scanning console output. For 7.1, we are working with the .NET System.CommandLine team to have appropriate APIs to decorate strings so that PowerShell can render them both with color as well as plain text, as needed. This includes addressing accessibility concerns where certain colors, themes, and decorations may be hard to see.

These experiences will require changes in both PSReadLine and the PowerShell engine itself.

We are also exploring some experiments such as Out-ConsoleGridView to make the console an even more productive experience.

Minimal PowerShell

One of the great things about PowerShell is the plethora of APIs and cmdlets you can use. However, the cost of this is that lots of assemblies are included with PowerShell just in case a script uses them. This works fine for authoring scripts, but when deploying scripts, it would be better to have your target only install the parts of PowerShell needed for those scripts. Not only would it take less disk space, but more importantly, a minimal set of code means less patching and security attack surface.

As part of this effort, we also want to split the monolithic Utility, Management, and Security modules that ship with PowerShell into logical modules that can be innovated and published on their own cadence.

Finally, to improve performance, we also want to look at reducing dependencies on .NET assemblies that are not absolutely needed to reduce memory usage as well as improve startup time.

Closing

As you can see, there is a lot of work we are current exploring and prototyping. Not everything will make it into the 7.1 release and may show up in a future release. As we make progress and have more concrete definitions and scope of the work, we will publish RFCs to get community feedback like we’ve done in the past. We will also leverage GitHub Projects to track progress and enable the community to provide feedback. I’m personally excited about the future of PowerShell and looking forward to seeing feedback on our plans!

Steve Lee
Principal Software Engineer Manager
PowerShell Team