As I previously mentioned a little over a month ago in my blog article PowerShell Script Module Design Philosophy, I’m transitioning my module build process to a non-monolithic design in development and a monolithic design for production to take advantage of the best of both worlds. Be sure to read the previously referenced blog article for more details on the subject. My goal is to write a reusable tool to retrieve the necessary information from a non-monolithic script module that’s necessary to create a monolithic version of the same module.

This blog article is the third in a series of learning about the PowerShell Abstract Syntax Tree (AST). Be sure to read the other two if you haven’t already. Learning about the PowerShell Abstract Syntax Tree (AST) Learn about the PowerShell Abstract Syntax Tree (AST) – Part 2 Learn about the PowerShell Abstract Syntax Tree (AST) – Part 3 In this blog article, I’ll be specifically focusing on finding the AST recursively.

In my previous blog article a few weeks ago on Learning about the PowerShell Abstract Syntax Tree (AST), I mentioned there was an easier way to retrieve the AST so that you didn’t have to cast everything to a script block. There are two .NET static methods, ParseFile and ParseInput, that are part of the Parser Class in the System.Management.Automation.Language namespace which can be used to retrieve the AST. First, I’ll store the content of one of my functions in a variable.

This week, I’ll continue where I left off in my previous blog article PowerShell Script Module Design Philosophy. Moving forward, the development versions of my PowerShell script modules will use a non-monolithic design where each function is dot-sourced from the PSM1 file. When I move them to production, I’ll convert them to using a monolithic design where all functions reside in the PSM1 file. In development, each PS1 file uses a Requires statement which specifies the requirements from a PowerShell version and required modules standpoint.