rules_nodejs
rules_nodejs copied to clipboard
Bazel not picking up changes in package.json
🐞 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?
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.
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"]
)
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.
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?
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.
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.
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!
This issue was automatically closed because it went 30 days without any activity since it was labeled "Can Close?"