Repository navigation
Create bundled Plaster template(s) #109
Description
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?
Activity
daviwil commentedon Sep 16, 2016
By the way, I'm thinking of putting the bundled templates inside of a
Templatespath under the module folder (a subfolder ofsrcin the repo). Thoughts?daviwil commentedon Sep 16, 2016
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 commentedon Sep 17, 2016
For the New Module template I have a couple of questions. First should it be called
New ModuleorNew 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
.publishfolder? 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 useOutor 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 commentedon Sep 17, 2016
Hmm, looks like we can use something like
[0-9].[0-9].[0-9]*in the.gitignorefile. And with version number I'm going to steer folks towards semver version numbers e.g.major.minor.patchwith no fourth (revision/qfe) number.daviwil commentedon Sep 19, 2016
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 theoutsuggestion) with a subfolder which has the module's name so thatPublish-Modulecan 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 commentedon Sep 19, 2016
AFAICT the only difference between an "empty" PowerShell module workspace and a DSC module workspace is the existence of the tags
DSC,DSCResource,DesiredStateConfigurationin 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.Check. I'll work on that.
Ooh, I like that. Sort of like a "publish local". I'll see if I can get that worked into the build script.
davegreen commentedon Sep 19, 2016
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 commentedon Sep 20, 2016
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 commentedon Sep 20, 2016
The build.psake.ps1 script needs updating to reflect recent decisions/changes we've made. It's on the
TODOlist. :-)rkeithhill commentedon Oct 5, 2016
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 commentedon Oct 5, 2016
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.