Replies: 1 comment
-
|
I have done a proof-of-concept that stores structured data in the lockfile instead of just raw BUILD files, and it seems to work (at least, for our use case). It cuts our MODULE.bazel.lock file size from 4MB to ~2MB, and removes all of the pages-long single lines, making lockfile diffs much easier to parse visually. At some point I will try to clean it up and propose a patch. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Our project has been "Bazel only" for a while. We're working on transitioning to a bzlmod-only structure, and I'm really appreciating the MODULE.bazel.lock-based storage of version information, removing the need for additional lockfiles, and letting Bazel itself handle the version pin management.
In our project's case, the only downside is that our MODULE.bazel.lock has become quite large. With our old WORKSPACE-style setup, the total size of all of our lockfiles amount to ~2MB. With the new bzlmod-style usage, the MODULE.bazel.lock has increased in size by 4MB! So it's quite a jump.
But worse, the new information in the lockfile is large unreadable, consisting of serialized BUILD files and serialized JSON objects.
So, I'm curious if the current structure is out of necessity, or if perhaps there's some way to store nicer, more structured (and perhaps more compact) data that can be used to reproducibly derive the necessary information that's currently stored in MODULE.bazel.lock, and it just hasn't been a priority thus far.
Beta Was this translation helpful? Give feedback.
All reactions