Bazel extension does not expose an API to other extensions

[gobeil]

It's possible for extensions to expose direct execution from other VS Code extensions:
https://code.visualstudio.com/api/references/vscode-api#extensions

...but the Bazel extension does not offer any API calls (Extension.activate() does not return a value), so other extensions are forced to re-implement capabilities that are already present in the Bazel extension, such as:

• Locating the WORKSPACE file
• Watching for BUILD file changes
• Querying for targets in a BUILD file
• etc...

[gobeil]

Is there resistance to opening up such an API (worries about maintenance or backward compatibility), or would the project maintainers be happy to accept a PR that implemented it?

[justhecuke]

I'll second this. You can't call the bazel commands from another extension because they require classes defined in the bazel extension.

It should be relatively easy to publish the classes to allow other extensions to call the main bazel commands which would allow other authors, including those at other companies, to create their own extensions that expand on what bazel can provide for the community. While I hesitate to pick and choose the public API for the maintainers, if they are willing to take a PR, then I can put one together relatively quickly so that we can allow others to use the defined bazel commands.

For example, inlining codelens into other language's source files like go, python, c++, java, etc... to perform common operations such as building, testing, and running would do a lot to increase user-friendliness to the vast majority of developers who dislike getting involved in build details.

[cameron-martin]

You can't call the bazel commands from another extension because they require classes defined in the bazel extension.

I think this is a separate issue to the one originally posted, but is a good idea. This is also needed for calling commands from a language server.