Support for PS5.1?

[gaelcolas]

I can see the module deliberately targets PS7+ only, is there a specific reason for that? or is it just because it was simpler to do so?
From a quick look, the only issue is the ternary operator, but there might be some challenges around the web cmdlets too?

[chris-peterson]

I don't routinely use anything prior to 7, so this is a testing coverage issue.

Maybe in "2.0" after I get some automated test suites in place, I could consider broadening the supported versions.

[gaelcolas]

Would you be interested in using a "build framework", to automate the build, test, release process?
Something like what we use over at https://github.com/dsccommunity/ ?
Or you can look at this: https://github.com/SQLBitsOrg/SQLBitsPS

We have a good chunk of the 90 modules using my Sampler framework (the glue sticking many other tools together), and enforcing test and quality checks?

I could probably transform your module and explain you...

Here's a talk by Raimund: https://www.youtube.com/watch?v=aoLiLDw0mGw

I'm need to take a dependency on a Gitlab module, so I want to make sure it's maintainable and we can enforce test/quality.

[chris-peterson]

Thanks for the links. I'm interested in learning more.

[gaelcolas]

Ok, I've started the conversion here:
https://github.com/SynEdgy/pwsh-gitlab/tree/f/move2sampler
(this is a work in progress, there's a few things I'm trying to grasp here, like why you ship with YamlDotNet dlls instead of depending on powershell-yaml).
You can git clone that repo, git checkout f/move2sampler branch and run ./build.ps1 -Task build to get a feel for it.
Then check the output/module folder.
Feel free to ping me on the PowerShell slack/discord if any question (aka.ms/PSDiscord or aka.ms/PSSlack).

[chris-peterson]

why ship with YamlDotNet dlls instead of depending on powershell-yaml
Introduced in 7679106

At the time, powershell-yaml was frozen in time at version 0.4.2. looks like the project has some new energy. I'll create an issue to try removing the workaround and using a plain-old dependency.

[chris-peterson]

Lots to digest in that branch... Thanks for putting in all this effort!

Initial thoughts

• Not sure how I feel about having every CmdLet in its own file. Might be a "best-practice", but I quite like having a submodule per domain
• There's a lot of boilerplate; is there a module that can be leveraged here? Or is this intentionally deduplicated for illustrative purposes?

I'll look closer in detail when I've got a little more time.

Thanks again.

[gaelcolas]

There's a lot of boilerplate

Lots of files, but all provide some features.
build.ps1, Resolve-Dependency.ps1, Resolve-Dependency.psd1 are the bootstrap for the process, the rest are configurations of some sort, specific to the project (hence why they should be in the repo).
build.ps1 is the entry point for all automation.
This pipeline leverages many modules (check the RequiredModules.psd1 for the list.

Not sure how I feel about having every CmdLet in its own file. Might be a "best-practice", but I quite like having a submodule per domain

When you do that, you now create $Global: variables, which are "bad" practices...
One function per file makes it easier to maintain (changes easier to "see"), easier to test (and audit/codeCoverage).
Less sub-module to load helps with performance.
Auto-generating the exported commands makes it less of a burden...

I can go on, but it'd be easier to jump on a call when you get time.