Prevent breakpoint lines from being included production code

[ghostsquad]

This looks really interesting, though I'm curious how you would prevent breakpoint lines from being checked into production code? It seems I'd have to be extra diligent, or run some sort of linting tool to check if I have any "breakpoint" or "ifdebug" lines in my scripts before committing.

[KirkMunro]

You're right, since these are not native commands, that means your code would have a dependency on the DebugPx module. I wish they were just natively included in PowerShell, but even if they add them at this point, they would only be in v.Next which is many, many years away from becoming my baseline version (which is currently v3, but I only recently switched to that as my baseline).

I'm not sure this is a huge issue for ifdebug commands because that is logic I wouldn't want removed from release builds. Otherwise, why go through the trouble of adding ifdebug, if it's only output that you'll use during dev/test work? The intent is to enable richer debug output (including gathering extra details that may take more time) from PowerShell but only when running with -Debug or $DebugPreference set to Continue.

Something that might help with this that I have considered: having a cmdlet in DebugPx that automatically removes ifdebug and breakpoint commands in a script or module that you specify. A command like that could be included in any release procedures to remove those statements prior to release. For my own module dev/test/release cycle that would work fine, because I do all dev work on one git branch (master) and all release builds that are signed go into another branch (release). For the dev/master branch, I wouldn't worry about having breakpoint/ifdebug in there (in fact, I may explicitly want them in there), but as part of my release automation I could clean those commands out of my scripts/modules if desired. Let me know what you think of that idea.

How do you handle releasing your PowerShell scripts/modules? Is it considered production the moment it is checked into source control? Or do you have a release procedure that signs your script files where the removal of breakpoint/ifdebug commands could happen? Understanding how others go through dev/test/release with PowerShell may also help me come up with something that works.

[ghostsquad]

I don't have a workflow right now, but I'm considering what it might be. Writing an function that parses the AST for breakpoint and ifdebug commands would be useful, and optionally removing either. A complimentary function that ADDS breakpoint and/or ifdebug statements to scripts (like Set-PSBreakpoint) would also be cool, though probably less useful, as I'll already be in the source code by the time I want to use that cmdlet.

I agree that ifdebug and other debug like statements should probably be ok to keep in production code. Though "production" could also mean cmdlets and scripts that are available to download from others (like your various modules). I'd want to keep the dependencies as lean as possible in that case.

[KirkMunro]

Yeah, module dependencies have been a sticky subject for a long time. I'm hoping with PowerShellGet that people get over that and start taking dependencies on other libraries (modules). That hope has been the main driver behind me creating so many small modules rather than one larger one that provides all of the functionality. Well that, plus I'll use small, focused modules over broad modules with less focus any day.

[ghostsquad]

I also started to move towards smaller focused modules. I'm developing a lineup that I've coined "Gravity". As it's an effort to bring various things together (like what gravity does), that help me (and hopefully others) code faster, better, and make testing easier. GravityPS is the core module, and the Gp are the small focused modules.