New feature: templating

[vernig]

It would be great to provide some templating (as the Twilio Serverless CLI provide templates / scaffolding for functions). I created an example of that on https://github.com/vernig/plugin-twilio-infra/tree/templates.

In this repo I use two flags:

• template which refers to a Twilio template scaffolding stored on https://github.com/vernig/plugin-twilio-infra/tree/templates/templates
• pulumi-template: this is the pulumi project template (which in the original project was an arg not a flag)

In order to try, you can use:

twilio infra:new --template taskrouter-quick-start

Currently this is only a proposed implementation and the templating needs to be expanded and more robust (e.g. including multiple files and folders)

@kaiquelupo what do you think?

[kaiquelupo]

That's exactly the plan for the next steps @vernig. As we discussed on the pull request, now we need to figure out the best way to create those template repos and decide if the pulumi tool for templating is good enough for our gols or if we should create our own. I really like the idea of templating not just in the sense of copying the code but also to keep people that copy the repo updated with the new fixes or features added to the template. Therefore, we need to assess the options here.

[kaiquelupo]

About the implementation you made, I wrote my opinion in here: #3

[bermudezmt]

Haven't had a chance to test @vernig 's addition to this repo yet, but wanted to add my comment in Slack for posterity: My main concern is around using an existing repo as a project template which I think is closer to what @kaiquelupo is referring to with "I really like the idea of templating not just in the sense of copying the code but also to keep people that copy the repo updated with the new fixes or features added to the template."

I am currently dealing with an issue in which the Flex CLI auto-removes code that it deems syntactically incorrect without any warning; thereby breaking the plugin.

[vernig]

Thanks @bermudezmt @kaiquelupo for the feed-back!

Just to summarise, we have to decide which of the following two flows to use:

CLI flow

• User install CLI
• Using CLI a user initialise a local folder and a pulumi project (infra:new)
• Optionally the user can specify a template, which in this case is a stab javascript file with an example implementation for the specific Twilio product (e.g. Task Router)

GitHub template flow

• User create a new repo based on template
• User works on this repo and made modification / customisation for its use case
• If there is any change / improvement / bug fixes, user can quickly merge the new change

I feel the two are both valid and complementary use cases.

The "GitHub template" flow is more for complex product, and (if I understood correctly @kaiquelupo ) forces the user to base its implementation on the template repo, so it may be more difficult to integrate with existing solutions.

The "CLI flow" is more similar to the Twilio Serverless CLI approach, where we provide simple scaffolding that are useful for getting something started (i.e. https://github.com/twilio-labs/function-templates for serverless). I agree we don't have to host all templates in the same repo, but I like the fact that all templates are grouped together (e.g. we can always create a monorepo?).

I feel the latter is a low hanging fruit that can make the use of the CLI and the pulumi provider easier to adopt, whereas the second is a medium / long term project that can definitely help more powerful user, but it takes more time to make it stable and robust.

So my proposal is to start working on a bunch of small templates to put out there, while we learn and improve the provider and the plugin CLI for a more ambitious series of product templates.

What do you think?

[bermudezmt]

Let's remember to discuss this at tomorrow's sync.