rules_nodejs icon indicating copy to clipboard operation
rules_nodejs copied to clipboard

Bazel not picking up changes in package.json

Open geoffliu opened this issue 2 years ago • 6 comments

🐞 bug report

Affected Rule

Maybe npm_install?

Is this a regression?

Yes, the previous version in which this bug was not present was: 4.6.0

Description

A clear and concise description of the problem...

🔬 Minimal Reproduction

Apologies in advance for the scarce information in this issue. We cannot reliably reproduce it, hope someone might point us in the right direction to debug.

We have intermittently observed that changes to package.json (and correspondingly, package-lock.json) are not being picked up by bazel. After the we change the version numbers of our dependencies, the build output is still using the old version. Doing a bazel clean --expunge solves the issue.

Not sure if it is related, but we recently upgraded rules_nodejs from 4.6.0 to 5.4.2, and the problem seems to have started around the same time.

We're a bit lost here, not even sure where to start. Happy to provide any information that might be helpful. Or if there are things to check the next time this happens, let us know.

🔥 Exception or Error






🌍 Your Environment

Operating System:

  
Linux
  

Output of bazel version:

  
Bazelisk version: {STABLE_VERSION}
Starting local Bazel server and connecting to it...
Build label: 5.0.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Jan 19 14:08:54 2022 (1642601334)
Build timestamp: 1642601334
Build timestamp as int: 1642601334
  

Rules_nodejs version:

(Please check that you have matching versions between WORKSPACE file and @bazel/* npm packages.)

  
5.4.2
  

Anything else relevant?

geoffliu avatar May 17 '22 15:05 geoffliu

Are you using managed_directories and symlink_node_modules in your WORKSPACE file? https://bazelbuild.github.io/rules_nodejs/dependencies.html#symlink_node_modules-and-managed_directories

We don't recommend that anymore, and it's the only thing that comes to mind which might explain the behavior you're seeing.

alexeagle avatar May 17 '22 15:05 alexeagle

We do not. The relevant section in WORKSPACE:

http_archive(
    name = "build_bazel_rules_nodejs",
    sha256 = "e328cb2c9401be495fa7d79c306f5ee3040e8a03b2ebb79b022e15ca03770096",
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/5.4.2/rules_nodejs-5.4.2.tar.gz"],
)

load("@build_bazel_rules_nodejs//:repositories.bzl", "build_bazel_rules_nodejs_dependencies")
build_bazel_rules_nodejs_dependencies()

load("@build_bazel_rules_nodejs//:index.bzl", "node_repositories", "npm_install")

node_repositories(
  node_version = "16.14.2"
)

npm_install(
  name = "npm",
  package_json = "//zed:package.json",
  package_lock_json = "//zed:package-lock.json",
  symlink_node_modules = False,
  data = ["//zed:.npmrc"]
)

geoffliu avatar May 17 '22 16:05 geoffliu

Perhaps sometimes you edit package.json but not package-lock.json? By default we run npm ci per https://docs.aspect.build/bazelbuild/rules_nodejs/5.3.0/docs/builtins.html#npm_install-npm_command so I'd expect you to get an error in that case.

I don't have any other guesses so I think we'll have to find some repro.

alexeagle avatar May 17 '22 16:05 alexeagle

Hi @alexeagle, thank you btw for the quick responses.

We are now seeing this on both Linux and Mac, on multiple team member's machines. Made sure we updated package-lock.json.

Any further info we can provide to help debug? Perhaps we could look directly into the bazel cache files and check their states?

geoffliu avatar May 18 '22 08:05 geoffliu

In case this is relevant: We use ts_project that depend on @npm//:node_modules, the output of which are fed into webpack rules for bundling.

geoffliu avatar May 18 '22 08:05 geoffliu

I think I have noticed this too. In my case, the problem isn't that bazel doesn't detect changes in package.json (i.e. it doesn't re-run npm/yarn_install rules). The problem is that downstream rules that should consume the freshly installed-npm dependencies use old/stale files, until bazel's output base is cleared out via bazel clean. I have noticed it with targets that use esbuild to bundle dependencies, although that should be taken with a grain of salt, given that I haven't investigated this at all yet.

Using RNJS 5.4.0

@geoffliu you could set quiet = False on your npm_install or yarn_install rule and confirm whether they are being triggered in your case.

matthewjh avatar May 23 '22 12:05 matthewjh

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[bot] avatar Nov 23 '22 02:11 github-actions[bot]

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

github-actions[bot] avatar Dec 24 '22 02:12 github-actions[bot]