When Good Enough Isn't Good Enough: Customizing Module Templates

Sometimes the perfect solution is almost perfect, but that “almost” becomes a real problem when you’re trying to automate everything.

After my previous post about Sampler, I was pretty happy with how it streamlined our PowerShell module creation. The scaffolding worked great, the quality checks were solid, and the team was using it successfully.

But then reality hit.

The “Minor” Issues That Weren’t So Minor

Sampler’s default configuration didn’t quite match our company’s specific needs. Nothing dramatic - just small things like:

• Different code coverage requirements
• Specific pipeline configurations for our Azure DevOps setup
• Custom folder structures we’d standardized on
• Particular module manifest settings our organization required

I documented the workarounds. Created a checklist of “things to change after scaffolding.” Made it work.

But this is automation we’re talking about. Having manual steps after using an automation tool just felt… wrong.

Enter Friedrich Weinmann

At PSConf.EU this year, I was paired with Friedrich Weinmann (Fred) as my speaker roommate. I’ve known Fred since PSConf.EU 2018, and I still remember my Twitter quote from that day:

“every #PowerShell module maker needs a @FredWeinmann … Wow..”

When I mentioned my Sampler customization problem to him, he had that familiar response: “I have a module for that…”

Meet PSModuleDevelopment

PSModuleDevelopment is Fred’s take on module scaffolding, and it shares a lot of DNA with Sampler. It can scaffold PowerShell modules and more (where Sampler has built-in DSC support, PSModuleDevelopment has Function App examples).

But here’s the key difference: PSModuleDevelopment is built from the ground up to support custom templates.

Getting Started

If you’re interested in trying PSModuleDevelopment:

1
2
3
4
5
6
7
8

# Install the module
Install-Module -Name PSModuleDevelopment -Repository PSGallery

# See available templates
Get-PSMDTemplate

# Create a new project from a template
Invoke-PSMDTemplate -TemplateName "MiniModule" -Name "MyAwesomeModule"

The Magic of Templates

Instead of being locked into default built-in templates, PSModuleDevelopment lets you:

• Create custom file templates
• Build complete project templates
• Store templates in so-called Stores
• Version and distribute templates across your team

Creating Custom Templates

I took my existing Sampler-based file and folder structure and created a Project Template that contained all the customizations our team needed. The process involves:

1. Creating the template structure - Your ideal project layout
2. Adding placeholder variables - Things like module names, author info, etc.
3. Building a Project Reference File - Metadata about your template
4. Publishing to your template store - Making it available to the team

Fred used an ingenious way of allowing you to template your own file/project by using a rarely used symbol þ, or thorn.
Because the whole setup is so easy, before you know it you can create a template from scratch or modify an existing template!

The Project Reference File

This is where PSModuleDevelopment really shines. The Project Reference File lets you define:

• Template metadata
• Required parameters
• Scripts to run during template creation
• Dependencies and requirements

It’s like having a smart installer for your scaffolding process.

Using Template Stores

A Template Store allows you to place all your File & Project Templates at a single location and PSModuleDevelopment will automatically recognize them and make them available for use within the module.
This way you can easily share your created Templates and make sure that everyone can use them in the blink of an eye.

Here’s how it works:

1
2
3
4
5
6
7
8

# Import the PSModuleDevelopment module
Import-Module -Name PSModuleDevelopment

# Check current template stores
Get-PSFConfig -Module PSModuleDevelopment

# Add a new template store (pointing to your local git repo)
Set-PSFConfig -Module PSModuleDevelopment -Name Template.Store.Shared -Value "c:\repositories\PSModuleTemplates\"

The name Shared is completely up to you - you could have different stores for different teams or purposes.

Real-World Benefits

Now when someone on our team needs a new module:

1. They run the template command
2. It creates the project with our specific configurations
3. No manual steps, no checklist, no “don’t forget to change X”
4. Everything works with our pipelines and standards immediately

The automation dream is finally real.

Version Control for Templates

If you store your templates in git repositories, we get all the benefits of version control:

• Track changes to our standards
• Branch and test new template versions
• Let team members contribute improvements
• Roll back if something breaks

Future Flexibility

The beauty of this approach is that we’re not locked in. We can:

• Evolve our templates as our standards change
• Take inspiration from both Sampler and PSModuleDevelopment defaults
• Create hybrid approaches that work for our specific needs
• Even build completely custom solutions if needed

The Key Insight

The real lesson here isn’t that PSModuleDevelopment is “better” than Sampler. Both are excellent tools that solve similar problems.

The insight is that flexibility in automation tools is crucial. When you’re trying to standardize across a team or organization, one-size-fits-all rarely actually fits all.

Having the ability to customize and extend your tooling means you can automate your actual workflow, not just approximate it.

Check out the documentation for the full picture of what’s possible.
And if there’s enough interest I might dedicate another blogpost on just how to customize and make your own new project template!

The Bottom Line

Sometimes “good enough” really isn’t good enough when you’re building automation for a team. The ability to customize your tooling to match your actual needs, not just approximate them, makes all the difference.

Thanks Fred, for having exactly the right tool for the job. Again…

Happy scripting! 😀