Write some boilerplate content to the bot project via storage at create time

[benbrown]

Describe the solution you'd like

In the past, during the "new bot" process, Composer would copy from a "templates" folder into the new project -- this was historically used to copy the entire bot project template.

We should bring back this feature, allowing us to copy some arbitrary boilerplate materials into every new bot project.

• In the future, this might also include things like a README file, deployment scripts, etc.
• Might include schema extensions
• This will be written to the storage system
• This will NOT include the entire bot code project.

I propose we re-instate the process of copying files from the templates folder into the project when creating a bot project. For now this can include a README file only.

[boydc2014]

Two questions

1. do we expect what's end up in bot's schema folder is the full version of schema or it's just the delta version (which user customized)

the reason asking is if it's full version
1.1 we need to check today we are purely schema-driven or not. because if we are not purely schema-driven, then it make less sense to do that or claim it's full version of schema.
1.2 And if it's full version, and if user update (not add) some part of schema, it probably won't work until there is runtime change. since those schema are not respected by sdk.

I feels like a little bit risky to put full version of schema in there and driven from bot, what if user accidentally remove or delete some part of that?
Will it make sense to put a baseSchema version into settings.json, and assume the bot's schema is only a overrride and adds-on to the baseVersion?

2. We are talking about both SDK.schema and uischema, right?

Again, I'm not sure do we already become purely schema driven, model UI schema in one single file now? I see multiple places called uischema.ts, and seems the previous ui.schema in server/schemas folder is not removed. I thought we can just copy that into each bot. @a-b-r-o-w-n any ideas on how can we do this?

[a-b-r-o-w-n]

The form is fully schema driven, so from it's point of view, it doesn't care where that schema came from. The only thing the shell needs to ensure is that a full schema is given to the form, including any user added customizations.

For the UI schema, it just needs to adhere to the interface defined in Composer/packages/extensions/extension/src/types/uiSchema.ts (minus any javascript). I am currently working on removing the iframe extension host which brings us a little closer to being able to send js into the extensions.

One quick note though: although technically a single runtime can operate on multiple bot's assets, what a "bot" is is a combination of content and runtime. The glue between those is the schema. So the problem of "what if a user changes the schema and the runtime that we manage doesn't support the change" is only a problem because we want to separate the runtime and the assets. So there may need to be some detection mechanism that can catch that case and have some UX for the user to correct it (by ejecting or something).

[a-b-r-o-w-n]

Oh and one more thing, I don't think there should be a default ui schema for a bot. Maybe an empty file.

[boydc2014]

Oh and one more thing, I don't think there should be a default ui schema for a bot. Maybe an empty file.

yes, i agree, i don't think we need to let the schema files in user's bot folder work as a totally replace, it should work as "override and extend".

regarding sdk.schema, by saying that when user update that, that might not work because user havn't update runtime i think it will happen even when we put runtime aside with declative assets (which is included in the latest proposal). The point i was trying to make is, there is an assumed schema that burns down firmly into code, not affected by an schema files.

For example, my SendActivity.cs expected one "Activity" field, if we exposed this schema into user's world, and user somehow add or rename this field, it will pass through in Composer UI and driven Composer to serialize an action node with new schema, and it would't work, regardless user find runtime code just aside or user find runtime elsewhere(in plugin).

So for me, i feels like for sdk.schema it should be also a "override and extend" approach, not a "full replace" approach, ie, only delta schema in user's bot folder. make sense? @a-b-r-o-w-n @benbrown

[boydc2014]

Per our discussion today, i'm closing this and creating a new issue here #2563 to track this.

[benbrown]

I am going to re-open this ticket to track work on the need to copy some boilerplate material into the project at create time, such as a readme file.

[boydc2014]

Hey @benbrown , i'm about to start add samples through plugin, and i'm thinking might take this together with a similar method to AddSample, like AddSampleTemplate, what do you think?

See here for the #2563 AddSample signature.

[benbrown]

@boydc2014 this is similar to how I did the addRuntimeTemplate too. Take a look at that for both of these.

[cwhitten]

addressed via #2837