Description of the bug:

MODULE.bazel.lock repeats content from package manager lockfiles, leading to serious developer experience regressions.

Desired behavior

As an example, in https://github.com/bazelbuild/examples/tree/611827d1bacfe83408cba2bbdcca4a801687d814/frontend

Bazel (via npm_translate_lock) starts from pnpm-lock.yaml [1] which fully specifies all the fields (URL, integrity) needed for rctx.download calls in rules_js.
When developers have a merge conflict in that file, they can just run the install again, because the tool is aware of git merge conflict markers. https://pnpm.io/git#merge-conflicts (the same is true for npm and yarn, the other popular JS package managers)

Note that in a big monorepo, it's very common to have lockfile merge conflicts because a PR that updates versions take a while to land (you have to green up all the usages) and in the meantime you need to rebase over other commits that have landed which also updated a dependency.

Also, when tooling like Dependabot updates their dependency versions, the lockfile is updated as well.

So, when the lockfile is updated, I would expect this entry in the MODULE.bazel.lock file to be trivially updated:

 "accumulatedFileDigests": {
    "@@//:.npmrc": "25afec638a4a1dc4a7277d8babd30464e9d942cf93d3e47505a4677adad1a901",
    "@@//:pnpm-lock.yaml": "656fb164bf8539b6945f307477907a7087d4b7b74db0e525065d1ba70898ebd5"
}

Actual behavior

However, when upgrading that repo to Bazel 7.0, we now get a MASSIVE Bazel lockfile, much larger than the original:

$ bazel query //...
$ wc -l MODULE.bazel.lock pnpm-lock.yaml 
 172470 MODULE.bazel.lock
  12893 pnpm-lock.yaml

Of these lines, nearly all are in this block:

"moduleExtensions": {
    "@@aspect_rules_js~1.32.2//npm:extensions.bzl%npm": {
      "general": {
        "bzlTransitiveDigest": "EkNX7WbLkG1/zKMTRsHgYFdQKwWxWuZMReEve7JbvqQ=",
        "accumulatedFileDigests": {
          "@@//:.npmrc": "25afec638a4a1dc4a7277d8babd30464e9d942cf93d3e47505a4677adad1a901",
          "@@//:pnpm-lock.yaml": "656fb164bf8539b6945f307477907a7087d4b7b74db0e525065d1ba70898ebd5"
        },
        "envVariables": {},
        "generatedRepoSpecs": {
... [170,990 lines elided] ...
        }
      }
    }
  }

Any merge conflicts in this file will present the developer with a massive headache, and they'll likely just delete-and-recreate the lockfile to get past it. Of course that's a bad practice as you've accidentally lost the pinning of all other Bazel modules.

Also, PRs from Dependabot will cause Bazel's lockfile to be out-of-date. Dependabot PRs are commonly security-related, so engineers have a great sense of urgency in merging them, and will again just work around the Bazel lockfile checking on CI or disable the feature.

[1] https://github.com/bazelbuild/examples/blob/main/frontend/pnpm-lock.yaml

Which category does this issue belong to?

External Dependency

What is the output of bazel info release?

7.0.0rc4