Plaster Use Cases #370
Replies: 5 comments
-
Hi! Discussed this with @gaelcolas the other day. One might imagine a situation where they could read a documented API (or even a config file they create) and dynamically generate a set of functions from those at module creation time. Not a hugely common use case, but just one example among others of where code execution would be beneficial. On the risks:
Gotta get to work, but again, love this project, looking forward to seeing it grow! |
Beta Was this translation helpful? Give feedback.
-
I think being able to create a folder/file structure based on a template and giving the user access to special variables that auto fill into the files would go a very long way. I even think you should give the user the ability to create their own variables for their own custom style projects. I have been sick the last few days, so I have not gotten to really play with Plaster, and I'm still reading over everything, so I am a bit behind. |
Beta Was this translation helpful? Give feedback.
-
@gerane You've pretty much nailed the user scenario we have implemented in this early preview. Take a gander at this example Plaster manifest - https://github.com/PowerShell/Plaster/blob/master/Examples/NewModuleTemplate/plasterManifest.xml It should give you an idea of the possibilities. And for file/template expansion, have a look at: https://github.com/PowerShell/Plaster/blob/master/Examples/NewModuleTemplate/MITLicense.txt |
Beta Was this translation helpful? Give feedback.
-
@RamblingCookieMonster do you really want to mix code generation into your scaffolding? |
Beta Was this translation helpful? Give feedback.
-
I have been thinking a little bit about use cases, and trying to get into the mode of thinking outside of the box. A few examples that I see being interesting:
I think there were some others that I am forgetting, but I'll try to add those as I remember them. |
Beta Was this translation helpful? Give feedback.
-
I wanted to start a thread here where folks can see our initial list of use cases. Propose others for debate and eventually wind up with a set of supported use cases for the initial release. Here is the set of use cases I have been working off of for the preview.
This may be an empty PSM1 file or an about_${ModuleName}.help.txt file with some boiler plate text in it or a module manifest file filled in with information gathered from the user.
For instance, projects targeting VSCode that supply tasks.json file need to put that file in a .vscode directory and if that directory doesn't exist, it needs to be created. Similarly a module manifest Pester test might go in a Tests folder.
Templates are just for initial project scaffolding. You can use them throughout project (module/dsc resource) development to: Add a new DSC resource or add PSake build support to a pre-existing module. Some additions might require modifications to existing files, like adding a new task to the VSCode tasks.json file.
I know some folks have wanted arbitrary code execution. This is something we're currently going out of our way to prevent. We want users who are expecting "scaffolding" i.e. the creation of files & folders, to be able to trust that the template isn't do something else. In fact, I haven't implemented it yet but I'd like for a user to be able to trust that the template will not modify anything outside of the
DestinationPath
they've specified. That said, if there are important use cases we're giving up, I'd like to know.Beta Was this translation helpful? Give feedback.
All reactions