I'm preparing version 1.0.0 of a dependency-free PowerShell library for clean, readable console output in interactive scripts such as installers and cleanup tools. It provides formatting and layout helpers, with the goal of complementing full logging frameworks rather than replacing them. The library is designed to be dot-sourced, remain compatible with PowerShell 5.1 and later, and work across Windows, macOS, and Linux where possible.
I'd appreciate constructive feedback on idiomatic PowerShell, parameter naming, error handling, cross-platform behavior, opportunities to simplify or improve the existing implementation, and any breaking changes that should be addressed before the first stable release.
The main function file is the focus of the review; demonstrations and tests are secondary. The current version intentionally has several limitations: it is not generally pipeline-enabled, does not integrate with verbose or warning streams, uses a custom visual test script instead of Pester, and avoids CmdletBinding because I'm not yet sure which functions need advanced-function behavior.
I'm especially interested in practical explanations such as "use this approach instead" so I can improve both the library and my understanding of PowerShell conventions.
2 Answers
A few quick improvements stood out. For a horizontal rule that fills the available console width, you can generate it from the current window size rather than hard-coding a length, for example `'-' * [Console]::WindowWidth`. For shared state, `$script:` variables provide module scope when the code is loaded as a module, avoiding unnecessary pollution of the caller’s scope. Keep in mind that dot-sourcing a script intentionally places its definitions and state into the caller’s session, so that trade-off comes with the portable single-file approach.
As the project grows, consider keeping each public function in its own source file and using a build step to combine them into the distributable script. That makes individual functions easier to navigate and review. It would also be worth adopting PowerShell comment-based help with `.SYNOPSIS`, `.DESCRIPTION`, `.PARAMETER`, and related sections instead of relying on informal comments.
There are existing cross-version approaches for colored and styled output that can work on both Windows PowerShell 5.1 and PowerShell 7 on Unix-like systems. A text-rendering library can build styled objects first and write them later, which also makes functions more pipeline-friendly than immediately calling `Write-Host`. That pattern could be useful if you eventually want formatting functions to compose with one another.
That said, adding a dependency would conflict with your goal of dropping one script beside another script and running it anywhere. Staying with native formatting is a reasonable choice; just document that portability goal clearly and make any terminal capability assumptions explicit.
That rendering approach is interesting, especially for pipeline support, but avoiding dependencies is important for this project. Sometimes the library needs to be copied directly onto a machine with the script, so I’m willing to accept the limitations of native PowerShell 5.1-compatible formatting.
These are helpful suggestions. I’m deliberately favoring a portable raw script over a module for now, although I understand that dot-sourcing removes the module scope boundary. Splitting functions into separate files is new to me, so I’ll investigate that workflow. I also wasn’t sure whether the documentation format being recommended was PowerShell-specific, but the comment-based help structure makes sense.