Create bundled Plaster template(s)

[daviwil]

Seems like we should include at least one template with Plaster so that there's something to use out of the box. I'd say we could take the existing example template and polish it up a bit so that it becomes a real starting point for a module.

What else would we need to add to that template to make it a decent starting point for a first initial release?

[daviwil]

By the way, I'm thinking of putting the bundled templates inside of a Templates path under the module folder (a subfolder of src in the repo). Thoughts?

[daviwil]

Another template we should include by default is one that can create a basic Plaster template. Since there will be some module manifest info that needs to be added to mark the module as containing a Plaster template, it'd be good to streamline that process so that template authors don't need to add everything manually.

[rkeithhill]

For the New Module template I have a couple of questions. First should it be called New Module or New PowerShell Module? I'm leaning towards the latter just to be a bit more specific.

Also, for preparing/building a module do we want to put the output in the current .publish folder? It's a little weird to call it .publish because it gets created as a result of "building" not publishing. And many folks will create modules that they'll never publish. I'm thinking maybe we use Out or perhaps as @Jaykul suggests <version-number>. For a module that uses a .psd1 we could grab the version number from it. However some modules may fore-go a psd1 and have only a psm1 and then there's no version number (perhaps just default to 1.0.0?).

On the plus side, you could do your development directly under ~\Documents\WindowsPowerShell\Modules\<modulename>\<version-number> and by the build script building "into" that version number dir, the module author can easily import their module under development. That said, how do we encode this folder into .gitignore. Can you specify a regex in a gitignore file?

[rkeithhill]

Hmm, looks like we can use something like [0-9].[0-9].[0-9]* in the .gitignore file. And with version number I'm going to steer folks towards semver version numbers e.g. major.minor.patch with no fourth (revision/qfe) number.

[daviwil]

I like "New PowerShell Module" too. On second thought, is it worth distinguishing between "Script Module" and "DSC Module"? Is that even a valid distinction?

For publishing, I'd avoid using the version number for folder naming for the reasons you mentioned. I'm not sure if there's an established pattern in the community yet for where you put your "built" files during development, but it might make sense to have a folder called release (similar to the out suggestion) with a subfolder which has the module's name so that Publish-Module can be used on it.

We could have a psake task called 'install' which will drop the files in the current user's module path if they want to test it that way. The upside of that vs always building into the module path is that the developer can choose when it happens.

[rkeithhill]

AFAICT the only difference between an "empty" PowerShell module workspace and a DSC module workspace is the existence of the tags DSC, DSCResource, DesiredStateConfiguration in the module manifest. Probably not worth a separate template. We could just ask the user for tags during Template processing or just ask if the template is for DSC. Then we can prepopulate the tags with the common tags for DSC.

folder called release (similar to the out suggestion) with a subfolder which has the module's name so that Publish-Module can be used on it.

Check. I'll work on that.

We could have a psake task called 'install'

Ooh, I like that. Sort of like a "publish local". I'll see if I can get that worked into the build script.

[davegreen]

The install/deploy local task would definitely be useful. I tend to use that kind of task a lot in my own psake workflow.

[davegreen]

I had a quick look into what it would take to perform the "publish local" action. The existing psake script for the plaster module was easy enough, which is always nice for testing, but the example NewModuleTemplate needed a bit of fiddling as the psake script threw some errors.

[rkeithhill]

The build.psake.ps1 script needs updating to reflect recent decisions/changes we've made. It's on the TODO list. :-)

[rkeithhill]

I've started a topic branch for this work specifically for the official NewModuleTemplate. It's time to start thinking about what we really want to have in this template. For instance, do we want to require the user to enter a Module description at this time? The example template does but I'm not sure we should for the official new module template.

I also don't think we should ask about the editor. If the module is launched from an editor, we should be able to query an environment variable or something to detect we are running inside VSCode (or ISE). And if the user runs this from the command line, they may not care about a specific editor or use an editor we might not have support for, so why ask this question.

[daviwil]

Agreed, module description probably isn't necessary. Also agreed that the template probably shouldn't ask which editor they use, but maybe we could ask "Would you like VS Code tasks to be created?" since there is some value there.

Alternatively, we could add some intelligence to the PowerShell extension to detect when a build.psake.ps1 script is present and then ask the user to generate a tasks file for it? That'd keep us from needing such logic in the template and it'd also allow the extension to refresh the tasks.json later if we figure out a better configuration.