Support really large repos better

thomasvl commented 4 years ago

This has come up in a few other issues, but addressing it seems to be non trivial. The main pain points:

The treeview starts by doing a query for all packages recursively. It would be nice if there was a way to do this progressively (like it does for targets within a package), but there doesn't seem to be a way to limit the depth of the package query.
There is no sharing of data between the treeview and quickpicks. If there was some "model" behind the scenes, then the quickpicks wouldn't have to issue queries if the model already had the data. There are a few complications though:
- The treeview can progressively load targets as the tree is expanded, but for the quickpicks, that doesn't work as well, so the quickpicks would need some decisions about how to let the users progressively expand things.
- Once data starts to be cached, how do things "refresh" when BUILD files are edited/added?

joshburkart commented 4 years ago

Thanks for providing this! Unfortunately, I'm finding the extension nearly unusable with my team's repo, AFAICT, due to its automatic querying. I frequently have to wait for this when running bazel on the command line:

Another command (pid=....) is running.  Waiting for it to complete on the server...

What about just having a settings toggle for disabling populating the "Bazel Build Targets" pane?

thomasvl commented 4 years ago

https://github.com/bazelbuild/vscode-bazel/pull/138 already provides a setting. It just hasn't been included in a release.

joshburkart commented 4 years ago

Ah okay great. Thanks!

Edit: In case it's useful to anyone, as a temporary workaround, I set the bazel.executable setting to a bogus path.

vogelsgesang commented 7 months ago

Maybe, implementing support for *.bazelproject files might also help here. Not sure, I don't work on large monorepos myself

bazel-contrib / vscode-bazel

Support really large repos better #162