New-ScriptFromTemplate

[jdhitsolutions]

I recognize that you are using this as an accelerator for your work, but if you are publishing a module for the public to use, you need to consider more than just your use cases. For example, when I create a new script file, you show as the author. 😁

You might also consider adding [ValidateNotNullorEmpty()] on the parameters. Maybe even a ValidateScript on the Path to verify the path exists. You can put all of your tests as parameter validations. You have no way of knowing how a user will pass parameter values to a function. Don't assume they are manually typing parameter values.

As for the template, you might consider re-designing this so that the template is an external file resource. You can provide a default in the module. That way, I can define my own template. For example, I have standard code I use in all my Begin blocks. Of course, you need to provide direction on how the template should be layed out.

You've got a decent start, but scaffolding commands are tough to build, especially when you are building a tool for anyone to use.

[jdhitsolutions]

Another quick thought - this function creates a script file or function. That is its job. It doesn't have to write to a file. That's what Out-File and Set-Content are for. All this command needs are parameters to define the function. Let it write the strings to the pipeline. If I want a file, I can pipe to Out-File. Or maybe I want to save the output to a variable so I can tweak it. Or append another function and then save to a file. Think about ConvertTo-HTML. It doesn't create a file. It converts objects to HTML. Period. Don't give a module command more to do than it has to, especially if there are native PowerShell commands that can be used in a pipelined expression.

[SamErde]

You’re right, I had started working on the Author name change in a different branch and got distracted/forgot to finish it.

Definitely need to split the template into a separate file as well. Funny enough, my first version of this (before putting it into the module) did use a separate file for the template. I was experimenting with an “all in one file” approach, and I can now confidently say there are numerous benefits to splitting it out. PSScriptAnalyzer and platyPS did not love parsing that one.

[SamErde]

I moved this to issue #11.

[SamErde]

Thoughts on this placeholder for a default author name?

PSPreworkout/src/PSPreworkout/Public/New-ScriptFromTemplate.ps1

Line 81 in 62db5d7

$Author = (Get-CimInstance -ClassName Win32_UserAccount -Filter "Name = `'$([System.Security.Principal.WindowsIdentity]::GetCurrent().Name.Split('\')[1])`'").FullName,

[jdhitsolutions]

That's a lot to do for a default value. Here's an idea. Write a few simple commands that let's the user define their default values, like name, company name, etc. Store the the values in a JSON file in $HOME. When the module is imported, test for the file and import the settings into a hashtable variable. Use the hashtable variable for your default parameter settings.

[jdhitsolutions]

Take a look at https://github.com/jdhitsolutions/PSFunctionInfo/blob/main/PSFunctionInfo.psm1 and related code as an example.

[SamErde]

I was thinking about doing that with Invoke-PSEnvironmentConfiguration, since that function asks for name already. What is an acceptable/recommended location within $HOME? Would this be a proper use case for $HOME/.PSPreworkout/PSPreworkout.json?

[SamErde]

Will check your example. Cheers.

[jdhitsolutions]

I would simply stick the file in the root of $HOME since that should also work cross platform.

[jdhitsolutions]

Here's a proof-of-concept using separate template files. This would be the template text file.

#requires -version @PSVersion

Function @Name {
    <#
    .SYNOPSIS
    @synopsis
    .DESCRIPTION
    @Description

    .PARAMETER Param1
    <Parameter Description>

    .EXAMPLE
    PS C:\> @Name

    <Example Description>
    .NOTES
    Author: @Author
    Version: @Version
    Date: @Date
    #>

    [cmdletbinding()]
    [OutputType('@Output')]
    [alias('@alias')]
    Param(
        [Parameter(
            Position = 0,
            ValueFromPipeline,
            HelpMessage = "<Parameter Help>"
        )]
        [ValidateNotNullOrEmpty()]
        [ObjectType]$Param1
    )

    Begin {
        Write-Verbose "[$((Get-Date).TimeOfDay) BEGIN  ] Starting $($MyInvocation.MyCommand)"
        Write-Verbose "[$((Get-Date).TimeOfDay) BEGIN  ] Running under PowerShell version $($PSVersionTable.PSVersion)"

    } #begin

    Process {
        Write-Verbose "[$((Get-Date).TimeOfDay) PROCESS] Processing"

    } #process

    End {
        Write-Verbose "[$((Get-Date).TimeOfDay) END    ] Ending $($MyInvocation.MyCommand)"
    } #end

} #close function

Replacements are indicated with @ signs like @Name. This code reads in the file and makes replacements based on a hashtable.

$temp = [System.Collections.Generic.List[string]]::new()
$temp.AddRange([string[]]$(Get-Content c:\scripts\jhFunctionTemplate.txt))

#define a hashtable to hold the values to replace in the template
$hash = @{
    Name        = 'Get-Busy'
    PSVersion   = '5.1'
    Author      = 'Jeff Hicks'
    Date        = (Get-Date).ToShortDateString()
    Version     = 0.1.0
    Synopsis    = 'This does something'
    Description = 'This is a long description of what the function does'
    Output      = $Null
    Alias       = 'gb'
}

$hash.Keys | ForEach-Object {
    $i = 0
    #loop through the collection and find the index number of the matching key
    #then replace the value in the template
    Do {
        $i = $temp.FindIndex($i, { $args[0] -match "@$_" })
        if ($i -ge 0) {
            Write-Host "Replace $_ at line $i" -ForegroundColor cyan
            $temp[$i] = $temp[$i] -replace "@$_", $hash[$_]
            $i++
        }
    } until ($i -eq -1)
}

#write update function to the pipeline.
#Let the user can decide what to do with it
$temp

Obviously, there are many ways to build the hashtable of values.