CLI and VS Code extensions versions are misleading users when using Kiota

[sebastienlevert]

Details to come, but right now as they are separate binaries, it's misleading that your "Local" version of kiota and VS Code version of kiota might be mismatching.

[baywet]

one thing we might be able to do here is to register the vscode "install" of kiota in the path. But that might really mess things up for people who already have it installed through other means. So we might want to provide a setting to disable that behaviour.

[sebastienlevert]

We were thinking the same. What would be the impact having a setting allowing to use the "global" kiota if it's available in the PATH already? How disconnected the VS Code experience and kiota CLI would be? Today, a lot of features are provided by the RPC server, but I assume if the VS Code extension and the global kiota becomes out of sync, this could bring issues.

That being said, I want us to think about how we can make these 2 binaries either work better together or literally be the same-ish binaries. Especially as today, even the Terminal experience in VS Code leverages the system-wide kiota, not the one from the extension with brings even more confusion.

Something to think more about as we invest more in the extension, therefore potentially creating more confusion.

[baywet]

having vscode use the global instead: since we don't version the JSON RPC API, and since vscode extension update automatically but not other installations, we might end up with a newer extension trying to talk to an older version of kiota and being broken. We could check the version and display an error message to the user to prompt them to update their global versions.

Another option we might want to consider is having the global install redirect calls to the vs code one if it's present, but that might be cumbersome.