[Bug]: @bazel/runfiles does not work with non-bzlmod when a _repo_mapping file exists
What happened?
When bzlmod is disabled it seems bazel7 still creates a .repo_mapping file which is configured different then when bzlmod is enabled.
Version
rules_nodejs with https://github.com/bazel-contrib/rules_nodejs/commit/21b56da9f20c9c5e8b8c1ac19052f1f7cc7b5920 and bazel7 with --enable_bzlmod=false
How to reproduce
Run the rules_js `e2e/runfiles` test with bazel7 and non-bzlmod: https://github.com/aspect-build/rules_js/commit/0cf77d9562d59c7a4e59269ba888ad21d4f99ce7
Any other information?
No response
A fix would be most welcome here. I noticed this when updating rules_nodejs in the course of trying to get a large repo ready for bzlmod....
I'm currently hacking around the problem via a patch applied in npm_translate_lock():
--- runfiles.js 2025-06-30 18:12:14.354935052 -0400
+++ runfiles.js 2025-06-30 18:12:40.529135868 -0400
@@ -110,6 +110,7 @@
parseRepoMapping(runfilesDir) {
var _a;
const repoMappingPath = path.join(runfilesDir, paths_1.REPO_MAPPING_RLOCATION);
+ return undefined;
if (!fs.existsSync(repoMappingPath)) {
// The repo mapping manifest only exists with Bzlmod, so it's not an
// error if it's missing. Since any repository name not contained in the
@jbedard Happy to help with this and review PRs, but my JS is rusty
The same logic should apply in the non-Bzlmod case. The file can still be non-trivial and needs to be taken into account, even with WORKSPACE.
I don't recall what the issue was. With non-bzlmod is the repo mapping any different or need extra logic?
I don't recall what the issue was. With non-bzlmod is the repo mapping any different or need extra logic?
There are instructions to reproduce in the issue description.
In my case (not using the reproducer instructions), I saw diagnostics like the following:
/home/dsanderson/.cache/bazel/_bazel_dsanderson/dffc63617bedb1750d2f16c6960dcd5a/execroot/__main__/bazel-out/k8-fastbuild/bin/j/js_/js.runfiles/__main__/node_modules/.aspect_rules_js/@[email protected]/node_modules/@bazel/runfiles/runfiles.js:148
throw new Error(`source repository "${sourceRepo}" not found in repo mappings: ${JSON.stringify(this.repoMappings, null, 2)}`);
^
Error: source repository "" not found in repo mappings: {
"aspect_bazel_lib": {
"__main__": "__main__"
},
"aspect_rules_js": {
"__main__": "__main__"
},
"aspect_rules_ts": {
"__main__": "__main__"
},
"bazel_tools": {
"__main__": "__main__"
},
"bsd_tar_linux_amd64": {
"__main__": "__main__"
},
"copy_directory_linux_amd64": {
"__main__": "__main__"
},
"coreutils_linux_amd64": {
"__main__": "__main__"
},
"local_config_shell": {
"__main__": "__main__"
},
"nodejs_linux_amd64": {
"__main__": "__main__"
},
"npm__at_bazel_runfiles__6.3.1": {
"__main__": "__main__"
},
"npm__at_types_is-number__7.0.0": {
"__main__": "__main__"
},
"npm__at_types_node__20.10.0": {
"__main__": "__main__"
},
"npm__is-number__7.0.0": {
"__main__": "__main__"
},
"npm__undici-types__5.26.5": {
"__main__": "__main__"
},
"npm_typescript": {
"__main__": "__main__"
},
"platforms": {
"__main__": "__main__"
}
}
at Runfiles.resolve (/home/dsanderson/.cache/bazel/_bazel_dsanderson/dffc63617bedb1750d2f16c6960dcd5a/execroot/__main__/bazel-out/k8-fastbuild/bin/j/js_/js.runfiles/__main__/node_modules/.aspect_rules_js/@[email protected]/node_modules/@bazel/runfiles/runfiles.js:148:23)
at Object.<anonymous> (/home/dsanderson/.cache/bazel/_bazel_dsanderson/dffc63617bedb1750d2f16c6960dcd5a/execroot/__main__/bazel-out/k8-fastbuild/bin/j/js_/js.runfiles/__main__/j/ts_program.js:16:34)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
at Module.load (node:internal/modules/cjs/loader:1207:32)
at Module._load (node:internal/modules/cjs/loader:1023:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12)
at node:internal/main/run_main_module:28:49
Node.js v20.10.0
and the repo_mapping file looks like this:
aspect_bazel_lib,__main__,__main__
aspect_rules_js,__main__,__main__
aspect_rules_ts,__main__,__main__
bazel_tools,__main__,__main__
bsd_tar_linux_amd64,__main__,__main__
copy_directory_linux_amd64,__main__,__main__
coreutils_linux_amd64,__main__,__main__
local_config_shell,__main__,__main__
nodejs_linux_amd64,__main__,__main__
npm__at_bazel_runfiles__6.3.1,__main__,__main__
npm__at_types_is-number__7.0.0,__main__,__main__
npm__at_types_node__20.10.0,__main__,__main__
npm__is-number__7.0.0,__main__,__main__
npm__undici-types__5.26.5,__main__,__main__
npm_typescript,__main__,__main__
platforms,__main__,__main__
With bzlmod enabled, the repo_mapping file looks like this, and the runfiles lookup does not blow up:
,__main__,_main
,aspect_rules_js,aspect_rules_js
,nodejs_linux_amd64,nodejs_linux_amd64
aspect_bazel_lib,__main__,_main
aspect_rules_js,__main__,_main
aspect_rules_ts,__main__,_main
bsd_tar_linux_amd64,__main__,_main
copy_directory_linux_amd64,__main__,_main
coreutils_linux_amd64,__main__,_main
nodejs_linux_amd64,__main__,_main
npm__at_bazel_runfiles__6.3.1,__main__,_main
npm__at_types_is-number__7.0.0,__main__,_main
npm__at_types_node__20.10.0,__main__,_main
npm__is-number__7.0.0,__main__,_main
npm__undici-types__5.26.5,__main__,_main
npm_typescript,__main__,_main
@jbedard If a pair (source canonical name, target apparent name) isn't found in the repo mapping, target apparent name should be used as the canonical name rather than raising an error. That also ensures correct behavior in the WORKSPACE case.