devynspencer / powershell-builder Goto Github PK

Should be empty instead. Unknown is weird.

Prompt for a noun and generate skelton functions for basic CRUD actions

GitHub username, repo name etc

Used for updating module manifest URIs and (maybe?) the .github files

An opinionated template for a PowerShell function built to support pipeline input and process multiple possible input types gracefully. The big one.

Unsure if this should be included or separate. If using a community-supported module like from psframework then including integration as part of the module template seems to make sense.

Wrapper for all publishing tasks - could alternatively resemble a build tool like gulp/npm.

• Run tests -- be a hero

• Update CHANGELOG.md -- if this could be done automatically based on a summary of git commits, it would blow my fucking mind

• Increment semantic version (maybe with a prompt for what kind of changes were made/how much it should be incremented by with examples for simplicity in the moment) -- update module manifest, anywhere else?

• Package the module, probably as a nuget package, and without superfluous/non-production artifacts like tests, docs, and examples

• Notify change control, SharePoint list/power app, Teams channel

• Allow exclusions (could these be added to manifest or?)

Tiny functions that do need parameters but (maybe) don't need comment-based help.

Template repository for quickly developing a new PowerShell module that integrates with a standard toolchain and development pipeline.

• Basic module tests -- template task already created somewhere
• Module profile/repository on package server -- probably not necessary before a nuget front-end
• Git repository setup script -- all local or could also create the repo on GitHub
• Publishing script(s)
• Documentation generator script(s)
• Directory structure (with placeholder folders?)
• Packaging script(s) -- include only the module code (no tests/docs/tools/licenses/changelogs); bundle separate files into psm1?
• README.md template -- or even better, generate/update it programmatically via a script
• CHANGELOG.md template -- again, generate/update programmatically via a script
• packaging metadata template -- whatever metadata nuget needs; might be superfluous with publishing/packaging scripts
• Dependencies on (yet-to-exist) helper module -- build-related functions and scripts distributed together as a module, if it makes sense
• Dependencies on non-build helper modules (logging, configuration, dsc integration) -- just an idea, but thinking of things like modules for formatting/sanitization/data structures/config data/remoting/encryption?
• Travis CI or similar configuration
• GitHub issue templates and other .github stuff
• VS Code per-project config files
• README.md files in private and public module directories -- generated from comment-based help and function names; is this overkill?
• Populate project URIs in module manifest -- i.e. the raw link to the GitHub repo, LICENSE file etc; should be able to customize endpoints for both personal and work projects
• gitignore excluding secrets
• psake or similar 'front-door' for issuing project-specific build commands

Resources

• https://ramblingcookiemonster.github.io/Building-A-PowerShell-Module/
• https://jdhitsolutions.com/blog/powershell/4994/creating-new-powershell-projects/

• Module manifest: LicenseUri property
• Module manifest: ProjectUri property
• GitHub issue templates etc.

There are a number of community-supported projects, but nothing in heavy active development at this time. Should the generation of modules be relegated to one of these modules, or should it be handled internally to reduce dependencies?

• https://github.com/PowerShellOrg/Plaster
• https://github.com/PoshCode/ModuleBuilder

LICENSE file currently created under the module directory, but it seems like it should be under the project root instead.

Came across this cool project today while digging myself out of NuGet hell: https://fsprojects.github.io/ProjectScaffold/index.html

Manifest generates with each of the ToExport properties set to '*'. This isn't best practice and hurts load performance from what I understand. I believe it should generate those properties as empty arrays instead.

Generate new functions in separate files based on the assumption that for every Add-Something function you (likely) also want a Remove-Something function for the same resource.

Could take this a step further with generating a project for mapping a REST API...