Add Command to "install" WebdriverIO in a project

[christian-bromann]

This should run the config wizard within VS Code and also add a GitHub action to the project if desired.

[mato533]

＃UPDATE:This is completely wrong.
This includes the discussion in #46.

Being able to configure WDIO from this extension means that the following conditions must be met
1. there are no WDIO-related assets such as wdio.conf.ts in the workspace
2. assumes that the extension must be enabled.

With the current design, this extension is not enabled in 1 state.
If this is in the plan, it seems to me that we need to allow this extension to be enabled in repository workspaces not related to wdio

[mato533]

This seems feasible, but the key point will be how to integrate the QA (implemented in inquirer) executed by the CLI

[mato533]

Possible options

1. When the install command is executed in vscode, launch the CLI in the vscode terminal and leave the rest of the processing to the CLI.
2. Extend the CLI to wrap inquirer and enable dependency injection from outside.
   →In the vscode extension, mimic the inquirer interface to enable UI responses.

remarks: We would like to avoid reimplementing the QA implemented in “@wdio/cli” on the VS Code side.

[christian-bromann]

@mato533 something we can do is to extract the questions and answers from the CLI into a separate package, e.g. move the whole questionaire feature into a e.g. @wdio/starter package. You can then import it and use it with VS Code primitives, e.g. native alerts and prompts. It's a bit more work but I think worth looking at especially as we wanted to better test this feature and moving it into a separate package would make it easier.

Thoughts?

[mato533]

@christian-bromann
Thank you very much!
I think it's a very reasonable proposal. In addition to the constant parts, I understand that the ability to write tests for dynamic questionnaires (such as the part that asks about the project path) is an advantage for @wdio/cli. For cli, I imagine using the questionnaire imported from @wdio/starter with inqirer, and for vscode, using it with ui.

I plan to start by extracting the core survey components from @wdio/cli to @wdio/starter.

[christian-bromann]

I plan to start by extracting the core survey components from @wdio/cli to @wdio/starter.

I wonder if we should just move everything into create-wdio which is the package powering the npm create wdio command. It is basically designed to help with this work. We could move the stuff there and have the @wdio/cli package import create-wdio instead. This avoids the creation of another package and adding more maintenance responsibilities on us. What do you think? You should have full access to that project.

[mato533]

@christian-bromann

I just visited the create-wdio code.
From what I can see, the responsibility is to install @wdio/cli, and after installation, it appears to be transferred to @wdio/cli. (In other words, it depends on @wdio/cli.)
The questionaire we are discussing now seems to be related to the CLI, not to create-wdio, so I am unsure whether it is appropriate to move it here.

By the way, when I said "new package," I was thinking of a subpackage of the webdriverio repository. (Create a wdio-starter directory next to wdio-cli.)

I imagine that this subpackage would be easier for maintainers to understand, but what do you think?

Even though it is only a subpackage, I think it is worth considering maintenance efforts. Based on the above considerations, create-wdio may be the best choice.

I just finished reading create-wdio, so please forgive me if I'm off base.

[christian-bromann]

No you are right, but this would be worthwhile to do right? Moving the whole wdio config logic into the create-wdio package which actually is suppose to do exactly that. Then remove the dependency from the create-wdio package to @wdio/cli and add the dependency from @wdio/cli to create-wdio.

At the moment the create-wdio package is just a thin wrapper to install the @wdio/cli package and call wdio config. I think it makes sense to move this code from the CLI into the create-wdio package. However I don't want to dictate the scope of the work. So I am also fine if the @wdio/cli package just exports the objects you need for the VSCode extension.