I should be able to create an API Plugin when opening the VS Code in a new window

[maisarissi]

1. When opening VS Code in a new window, we should not show the workspace error:
   
2. The default folder in this situation could be like C:/Users/<user>/KiotaGeneration (we can come up with a better folder name too )
3. Then, once the generation is successful, we should open a new window in the right folder (the default or the one chosen by the user). The Kiota extension state here, should be the same as when I'm creating a new plugin in an existing folder, we should load the API Explorer with the plugin name and the right selected endpoints, the workspace is shown in the My workspace panel.
4. We should not show the following message:
   

[sebastienlevert]

I would suggets ~/kiota just to make it simpler.

[baywet]

For context, this is where the exception comes from. We could set the default to the path Seb suggested instead. And maybe show a warning?

kiota/vscode/microsoft-kiota/src/extension.ts

Line 311 in 21ba633

vscode.l10n.t("No workspace folder found, open a folder first")

[maisarissi]

Not sure we need a warning, but I'm ok with the folder ~/kiota folder.

[ElinorW]

@maisarissi so, the issue here is that the workspace.json file doesn't get generated in the output folder...
It goes to the .kiota folder...
so opening a new window with the output folder may show the generated files but the workspace.json file will still be missing and I'm not sure how regeneration would work, since the location of the workspace.json file would be unknown
what should we do about that?

[maisarissi]

Are you saying that the issue here is after generation is done and we are opening the VS Code in the output folder?

If so, can we open the VS Code instance in the parent folder of .kiota?
Example: If I chose my output folder to be C:/~/TTK/GitHub/appPackage/, in that case, the sliced OpenAPI and the plugin will be created in the appPackage folder but .kiota will be created in GitHub/.kiota, then we should open VS Code in the GitHub folder. If I'm choosing C:/~/TTK/GitHub/ as output directory, the sliced OpenAPI and the plugin will be created in the GitHub folder, as well as .kiota. So we should still open the VS Code in the GitHub folder.

[ElinorW]

I'm choosing C:/~/TTK/GitHub/ as output directory, the sliced OpenAPI and the plugin will be created in the GitHub folder, as well as .kiota. So we should still open the VS Code in the GitHub folder.

I still have a few concerns:

• With the example you've shared I assume the user has selected this as their output path and they aren't using the default option? i.e. "C:/Users//kiota
• A user's output directory might not always be straightforward. The logic to determine the correct parent directory (where .kiota is created) can get complex, especially if users have different directory structures or naming conventions.
• What is the user expectation? I would think they expect the output directory to be the workspace opened, opening the parent directory could lead to confusion e.g if we want the default to be "C:/Users//kiota" then the parent directory will be the "username" folder... which is what would be loaded

[maisarissi]

How we determine where to create .kiota? Can't we use that logic to know the parent folder to open the right thing?
For me, we should open the VS Code on the /.kiota parent folder, so the user will have a view for the entire project since the plugin generation is not only the plugin files, but also the workspace.json, the copy of the original OpenAPI file + the generated files.
But would love to hear from @sebastienlevert @baywet whether they have a better idea.

[baywet]

right now the behaviour is driven by vscode. Whatever folder is opened in vscode is the workspace (independent from kiota, bottom bar is blue, not purple). We then use that folder as the current working directory for kiota's engine. That means when anything needs to be accessed/generated, it'll be relative to this directory.

I honestly do not see any value in generating to a random location (plugins/clients), the workspace notion seems to be well understood by vscode users, and they'd have to find whatever random place we generated things into and move it to the right place. (VS used to do that, and probably still does to this day with the "new project" wizard, and this has caused so much annoyance.)

Now, I understand that we don't want to be greeted by an error message when we open vscode without a workspace opened. This didn't use to be the case with the "mainline" extension version. My guess is this error message is getting triggered by the "my workspace" panel trying to query for state. I think the only thing we need to fix here is to avoid querying for status whenever a workspace is NOT opened so we don't trigger this error message.

Thoughts?

[baywet]

In fact I think I have solved this issue with #4963, it remains to be tested though.

[baywet]

in fact I just tested my suggested fix, works like a charm. The behaviour is:

• no more error messages
• if a workspace is open, try to load the file from there.
• if the file is absent, be quiet
• when clicking on the file entry in the workspace, if the file is absent, create it
• if no workspace is open, same logic applies, but at the user home directory.

[ElinorW]

@baywet so what happens when a user generates the code without any workspace open? does vs code open the home directory as the workspace?

[baywet]

The generation is the only scenario I have not tested yet. What works now with my pull request is opening vs code with no error message and opening the workspace file with no error message. I think that your PR from briefly looking at it has what it needs for the generation part. I noticed your PR after I pushed mine. If you don't mind merging the 2 and taking it from there?

[ElinorW]

Sure thing

[ElinorW]

Fixed in #4958