Create Runtime Settings page

[benbrown]

Is your feature request related to a problem? Please describe.

By default, new projects created in Composer will not contain the code needed to run the project. This will be provided automatically by the localPublish plugin that manages the local run/test cycle.

However, for bots that have a customized runtime or for existing projects that use Composer to edit declarative dialogs, developers need a way to manage that behavior.

Describe the solution you'd like

Composer needs a settings page where the location and behavior of the runtime can be configured.

Runtime behavior setting

This setting will control how the localPublish plugin handles the runtime for local testing.

• By default, new projects will ship with these options turned off, or in a default/disabled mode.
• A developer should be able to enable the custom runtime. This should be a toggle switch that, when enabled, allows the user to modify 2 related settings: the path to the runtime, and the command used to start the runtime.
• The path should use the local filesystem browser widget to allow a user to browse for a folder and select it in the UI.
• The start command should be a freeform text field.

If the custom runtime is enabled, the localPublish plugin will use these fields instead of using the "built in" runtime. See #2450 for details.

Eject runtime feature

As stated above, the default behavior is that new projects do not include the bot project code. However, we still need to provide this code to some developers at some point so they can extend or customize it.

The eject feature should:

• Include a brief description of what will be provided
• Allow user to pick from 1 or more runtime templates. (C#, Javascript, Python, etc)
• Composer automatically "migrates" the current project to include the code AND the assets. the runtime will be written to a sub-folder of the bot project, and will be automatically configured to use the local bot assets.

[boydc2014]

A few points

1. do we want allow user to configure the path to the runtime

I like that, but i just want to clarify the implication of this, because by saying that, we are saying we don't assume the bot runtime live with the bot assets.

If that's true, when we are selecting a bot to open, we can't select the runtime+declarative folder a whole bot, right, because there is not way to judge the whole folder is a bot or not.

So for us, we either say
a. any bot opened by composer must open from the declarative folder, in this approach, Composer core is still a editor only cares about declartive bits, there wouldn't be two modes. Actually i like this way.
b. if we want treat the runtime+declartive assets a whole bot to open\view in Composer, like the old days, we should not allow user to specify "a location to runtime" and the path to declarative assets is no going to be configurable.

I like a), because, supporting two modes (normal mode and ejected mode) sounds like we are looking for trouble.

2. eject feature
   It's appealing to do it in place and auto migrate that. But it won't work well when user's bot(declarative assets) sits in remote storage.

And because our ejection is not a "eject and don't care anymore", so, if we can't guarantee ejecting perfectly, it would be risky to do that in place. I would rather to do it in a read-only approach to original bots, generating a new bot probably named (bota-ejected) and let user download it or choose to save it somewhere, probably only local.

Then after ejecting to certain place, we go back to problem 1, how do we want user to open it.

[benbrown]

I have done a first pass of this, and opened a draft PR #2572

So far, all I've done is the basic UI for the settings. This UI is still in flux.

https://www.figma.com/file/LlTlh5vXwq91zjGnFtrUUR6l/Composer-master-design-spec-%2F-UI-library?node-id=1111%3A11474

[benbrown]

Today:

• added popup for selecting template
• added plugin features for adding runtimes to the list
• added api for getting list of available runtimes

• update plugins/readme
• call api to get list of runtimes
• move current template into the localPublish plugin
• perform actual eject

[benbrown]

have actual working file copy from plugin now.
need to do some error correction, UI fixes, and move the actual template code.

[cwhitten]

Let's make sure to include @garypretty 's efforts in this workstream around serializing some telemetry specific information to the settings file and the runtime template here: #2697

[cwhitten]

#2572 (comment)