-
-
Notifications
You must be signed in to change notification settings - Fork 631
Open
Labels
cleanupTech debt, resolving it improves our own velocityTech debt, resolving it improves our own velocitytype: process
Description
It's become a bit of a pain to manage all the bzl_library targets. A tool to deal with it would be much nicer.
I made a quick try and using https://github.com/bazelbuild/bazel-skylib?tab=readme-ov-file#gazelle-plugin
It mostly worked, but had the following problems:
- Our local_repository() hack in workspace broke it. I had to comment that out. This is a hack for Bazel 9+workspace. Could possibly remove it, since workspace may be dropped in bazel 9
- It rewrote all our build files. It's convention is
{name}
for bzl_library, not{name}_bzl
. Renaming our internal targets is feasible, but we have to retain the public targets naming. - It added go_proto_library everywhere. We don't need or want that.
- I think it rewrote various other targets. I'm not against that, per se, however, I'm not a fan of the giant comment blocks configuring gazelle. I'm also wary of gazelle changing its preferred naming behavior and churning a lot.
- The normal setup has us put a load for gazelle in our root build file; we can't do this as it would make gazelle a prod dependency, when it needs to be a dev-only dependency. Maybe if we just move it to tools/private?
The functionality we need is:
As an alternative, I have a tool that mostly handles bzl_library stuff almost done. It just does two things: generating bzl_library, and sorting names in build files.
cc @dougthor42
Metadata
Metadata
Assignees
Labels
cleanupTech debt, resolving it improves our own velocityTech debt, resolving it improves our own velocitytype: process