PowerShell Plans for 2022

I'm not much for writing year in review pieces. Nor, to be honest, do I often write New Year's resolutions. But I've been thinking about the work I've done this past year and what I might be doing in 2022 so I thought I'd share some thoughts on what 2022 will look like for me, especially in terms of PowerShell.

Obviously, PowerShell is a driving force in my professional life so these are carefully considered decisions. And maybe these are items you have been debating yourself and simply needed someone to give you at least tacit approval.

Conferences

The first item isn't as much a goal as it is a wish. I am very much looking forward to returning to the PowerShell + DevOps Global Summit in April. I will be co-hosting the OnRamp program with Tim Warner and look forward to seeing many of you in person. I'm hoping the PowerShell by the River event will be on track again in 2022 and I'd love to travel to a PowerShell Saturday event or two.

Pester 5.x

I will be honest and tell you that my Pester work dropped off dramatically with the release of Pester 5. This version was a major upgrade and restructuring of how a Pester test is written and executed. I kept putting off learning about the changes and wrote very few Pester tests for my new modules. In 2022, I'm going to change that.

First, I'm not about to go back and edit all of my existing Pester tests. I have a workflow that loads a legacy version of Pester to run my tests. This is like the early days of PowerShell when people were transitioning from VBScript. My suggestion at the time was that if you had a working VBScript there was no need to rewrite everything in PowerShell. But for new tasks, begin using PowerShell. I'm going to follow this model.

I will leave my existing Pester tests alone unless I find I need to add new coverage or discover a bug. At that point, it might be worth it to revise the tests to use Pester 5.x. However, for new Pester tests, I will write them using Pester 5.x. This also means I need to get back in the practice of writing Pester tests for my PowerShell module. I've let that slide the last year or so and need to get back on track.

PowerShell 7.2

My other primary goal for 2022 is the most dramatic but I think it is time. Ever since PowerShell 7 was introduced, I tried to write my PowerShell modules to work in both Windows PowerShell and PowerShell 7. If I could support cross-platform, so much the better. But looking back now, I see that my focus was still on Windows PowerShell. But that needs to change. PowerShell 7.x has been available for some time. And while I don't expect people to necessarily update Windows Servers to PowerShell 7.x, you should be able to use PowerShell 7 on your desktop and still manage your environment.

Going forward my new PowerShell modules will be written with PowerShell 7.x in mind, wherever possible. Specifically version 7.2. I am not going to mark my modules as compatible with Windows PowerShell nor spend the time testing. It is certainly possible that some of my new modules might work just fine in Windows PowerShell, or only require minor revisions for compatibility. But I will leave that process to you should you need it. You can always fork one of my module's repositories and revise it to fit your requirements.

By committing to PowerShell 7.2 I can take advantage of new operators like the ternary operator, new cmdlet parameters like -Parallel in ForEach-Object, new features like $PSStyle, or new modules like Microsoft.PowerShell.ConsoleGUITools.

In fact, I expect to focus much of my online writing on PowerShell 7.2. Windows PowerShell isn't going away any time soon and will always have a place until all of the modules that IT Pros rely on are revised for .NET Core. The best way to learn is by doing and it makes sense to me to invest time and energy in the future of PowerShell. I hope you'll join me.

---

---