rules_nodejs icon indicating copy to clipboard operation
rules_nodejs copied to clipboard

[Bug]: @bazel/runfiles does not work with non-bzlmod when a _repo_mapping file exists

Open jbedard opened this issue 1 year ago • 7 comments

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

jbedard avatar Oct 16 '24 22:10 jbedard

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....

dws avatar Jul 01 '25 13:07 dws

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

dws avatar Jul 01 '25 13:07 dws

@jbedard Happy to help with this and review PRs, but my JS is rusty

fmeum avatar Jul 01 '25 15:07 fmeum

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.

fmeum avatar Jul 01 '25 18:07 fmeum

I don't recall what the issue was. With non-bzlmod is the repo mapping any different or need extra logic?

jbedard avatar Jul 02 '25 22:07 jbedard

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

dws avatar Jul 03 '25 00:07 dws

@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.

fmeum avatar Jul 03 '25 06:07 fmeum