Regression: transitive dependencies not propagated

[Daniele Polencic]

Homeworks:

• Searched on Bazel slack, found nothing.
• Searched through previous issues, I think this might be related (or the same, not 100% sure).

Affected Rule

I think the issue is with npm_package_bin or ts_project. Something is not propagating dependencies.

Is this a regression?

Yes, this works on 4.7.1, but it does not on 5.5.1. See demo below.

Description

1. I have a npm_package_bin action that bundles a JS file and all its dependencies into a single JS file.
2. A package called dep uses the bundler action to create a single JS files and adds it to a js_library.
3. The dep package is included in a main package that runs a simple console.log.
4. I execute the action for the main package.

All of this works on 4.7.1.
However, it does not on 5.5.1, which errors with:

INFO: Analyzed target //packages/main:main (56 packages loaded, 546 targets configured).
INFO: Found 1 target...
ERROR: /private/tmp/my_workspace/packages/dep/BUILD.bazel:28:20: NpmPackageBin packages/dep/bundle.js failed: (Exit 1): ui_bundle.sh failed: error executing command bazel-out/darwin-opt-exec-2B5CBBC6/bin/packages/dep/ui_bundle.sh --output-dir bazel-out/darwin-fastbuild/bin/packages/dep --entry-point bazel-out/darwin-fastbuild/bin/packages/dep/bundleme.js ... (remaining 5 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox
Error: Cannot find module 'rollup'
Require stack:
- /private/var/tmp/_bazel_user/89eb77117286e8578fa6ee9ae19905d4/sandbox/darwin-sandbox/102/execroot/my_workspace/bazel-out/darwin-opt-exec-2B5CBBC6/bin/packages/dep/ui_bundle.sh.runfiles/my_workspace/packages/bundler/index.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (private/var/tmp/_bazel_user/89eb77117286e8578fa6ee9ae19905d4/sandbox/darwin-sandbox/102/execroot/my_workspace/bazel-out/darwin-opt-exec-2B5CBBC6/bin/packages/packages/bundler/index.ts:2:1)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
Target //packages/main:main failed to build
Use --verbose_failures to see the command lines of failed build steps.
ERROR: /private/tmp/my_workspace/packages/main/BUILD.bazel:3:14 Middleman _middlemen/packages_Smain_Smain.sh-runfiles failed: (Exit 1): ui_bundle.sh failed: error executing command bazel-out/darwin-opt-exec-2B5CBBC6/bin/packages/dep/ui_bundle.sh --output-dir bazel-out/darwin-fastbuild/bin/packages/dep --entry-point bazel-out/darwin-fastbuild/bin/packages/dep/bundleme.js ... (remaining 5 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox
INFO: Elapsed time: 15.329s, Critical Path: 1.93s
INFO: 53 processes: 1 disk cache hit, 7 internal, 45 local.
FAILED: Build did NOT complete successfully
FAILED: Build did NOT complete successfully

🔬 Minimal Reproduction

The following repo contains a minimal example. You can execute the project with: bazel run //package/main. Please note:

1. The master branch fails because it uses 5.5.1.
2. You can switch to the branch 4.x to make the code succeed.

🌍 Your Environment

Operating System:

  
macOS 10.15.7
  

Output of bazel version:

Bazelisk version: development
Build label: 5.0.0
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Jan 19 14:15:55 2022 (1642601755)
Build timestamp: 1642601755
Build timestamp as int: 1642601755

[Greg Magolan]

I'm not sure of the underlying cause but the symptom is that the npm deps from your ts_project bundle_lib target are not being propagated through the <name>_bundle nodejs_binary to the npm_package_bin that uses the binary as a tool.

    deps = [
        "@npm//@rollup/plugin-commonjs",
        "@npm//@rollup/plugin-json",
        "@npm//@rollup/plugin-node-resolve",
        "@npm//@types/node",
        "@npm//rollup",
        "@npm//rollup-plugin-node-polyfills",
        "@npm//rollup-plugin-sourcemaps",
    ],

If these are propagated manually like so

$ git diff
diff --git a/packages/dep/BUILD.bazel b/packages/dep/BUILD.bazel
index e695624..a5cb2d8 100644
--- a/packages/dep/BUILD.bazel
+++ b/packages/dep/BUILD.bazel
@@ -27,7 +27,15 @@ ts_project(
 
 single_file_bundler(
     name = "ui",
-    data = [":ui_lib"],
+    data = [
+        ":ui_lib",
+        "@npm//@rollup/plugin-commonjs",
+        "@npm//@rollup/plugin-json",
+        "@npm//@rollup/plugin-node-resolve",
+        "@npm//rollup",
+        "@npm//rollup-plugin-node-polyfills",
+        "@npm//rollup-plugin-sourcemaps",
+    ],
     entry_point = "bundleme.ts",
 )

then the build succeeds

[Daniele Polencic]

@gregmagolan, thanks for looking into this. The issue is that this works fine in 4.x. Somehow the deps are propagated correctly there.
I'm aware that I can manually link the dependencies. This is somehow similar to the workaround I used in #3182
However, since the issue is similar to #3182 and happened around the same time, I wonder if the fix could also be the same.

If not, I guess my question is: should I just link the third-party dependencies and move on? My goal is to migrate to rules_js, but 5.x is a requirement, and this issue is blocking the migration (i.e. the plan is rules_nodejs 4.7 (current) -> 5.5 -> rule_js).

[Greg Magolan]

We need to upgrade the migration docs for rules_js as you can upgrade to it from rules_nodejs 4.x. build_bazel_rules_nodejs 4.x doesn't use the rules_nodejs core package that rules_js depends on for its toolchainsm, so there is no conflict with bringing in rules_js in a workspace with build_bazel_rules_nodejs 4.x.

Either way you have the issue of interop if you want to rules_js targets to depend on rules_nodejs targets (or vice versa). It is possible to have interop but the approach to take depends on how your project is structured and in what order you want to migrate your targets.

[Daniele Polencic]

[...] as you can upgrade to it from rules_nodejs 4.x.

This is excellent news!

It is possible to have interop [...]

Is this documented somewhere? I could not find any reference here https://docs.aspect.build/aspect-build/rules_js/v1.0.0-beta.0/docs/migrate.html#migrating-to-rules_js

[Greg Magolan]

Some documentation and examples of different interop patterns would be nice to get up at some point. I suspect that there will be enough variance between how different rules_nodejs projects are setup that it would be hard to cover all cases given there are many ways to setup rules_nodejs projects.

We're still working to get rules_ts and the remaining derivate rule sets to 1.0.0 so stretched thin at the moment for migration docs & examples and open source work in general. We are helping a few Bazel support clients migrate so the documentation will naturally come from those efforts over time.

[Greg Magolan]

Updated the migration guide at HEAD to indicate that build_bazel_rules_nodejs 5.x is not required, https://github.com/aspect-build/rules_js/blob/main/docs/migrate.md#upgrade-to-rules_nodejs-50-or-greater

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 6 months. It will be closed if no further activity occurs in 30 days. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

[github-actions]

This issue was automatically closed because it went 30 days without any activity since it was labeled "Can Close?"