[Bug]: Setting `ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK` disables `update_pnpm_lock` until repo generated by `npm_translate_lock` is deleted

[kcon-stackav]

What happened?

I recently configured my repo to set update_pnpm_lock = True in my npm_translate_lock() call in MODULE.bazel following all of the instructions described here: https://docs.aspect.build/rulesets/aspect_rules_js/docs/pnpm/#update_pnpm_lock

I am setting the ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK environment variable to 1 in my CI environment generally, so that only a specific CI job/step reports if the pnpm lock file is outdated as described at the above link:

If the ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK environment variable is set, update_pnpm_lock is disabled even if set to True. This can be useful for some CI uses cases where multiple jobs run Bazel by you only want one of the jobs checking that the pnpm lock file is up-to-date.

However, I noticed that once Bazel has been run with the ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK environment variable set, further invocations of Bazel will no longer respect update_pnpm_lock = True (i.e. if your pnpm-lock.yaml file is outdated then Bazel won't run pnpm install ... to update it nor fail if you set ASPECT_RULES_JS_FROZEN_PNPM_LOCK=1), even if I completely unset the ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK environment variable (not just empty it but completely remove it from the environment, e.g. using env --unset=ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK bazel build ...).

Interestingly the opposite direction works as desired, so if ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK=1 has never been set then Bazel respects update_pnpm_lock = True, but then once you do set ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK=1 then update_pnpm_lock will be disabled.

Version

Development (host) and target OS/architectures:

❯ cat /etc/lsb-release                                                                                                                                                              
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"

❯ uname -m 
x86_64

Output of bazel --version:

❯ bazel --version
bazel 7.2.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

Via MODULE.bazel, 1.42.3 from BCR

Language(s) and/or frameworks involved:
TypeScript, but maybe N/A to this issue

How to reproduce

No response

Any other information?

I'm currently using the following workaround in the specific CI job step that I want to check if the pnpm lock file is outdated, by deleting the repo generated by npm_translate_lock and then shutting down the Bazel server so that the next bazel invocation will recreate it but this time with update_pnpm_lock = True being respected as long as I also unset ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK:

rm -rf "$(bazel info output_base)/external/aspect_rules_js~~npm~npm"
bazel shutdown # seems to be required, otherwise the next bazel invocation fails
env --unset=ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK ASPECT_RULES_JS_FROZEN_PNPM_LOCK=1 bazel run '@@aspect_rules_js~~npm~npm//:sync'

I'm wondering if rules_js may need to use this feature of Bazel to declare more formally that it's sensitive to the ASPECT_RULES_JS_DISABLE_UPDATE_PNPM_LOCK environment variable: bazelbuild/bazel#19511

I'm not sure rules_js is currently doing that either via the environ attribute of the repository_rule:

rules_js/npm/private/npm_translate_lock.bzl

Lines 146 to 149 in f0c67a2

	npm_translate_lock_rule = repository_rule(
	implementation = _npm_translate_lock_impl,
	attrs = _ATTRS,
	)

Nor using the repository_ctx's get_env() method (instead rctx.os.environ appears to be used directly):

rules_js/npm/private/npm_translate_lock_state.bzl

Lines 569 to 571 in f0c67a2

	if RULES_JS_DISABLE_UPDATE_PNPM_LOCK_ENV in rctx.os.environ.keys() and rctx.os.environ[RULES_JS_DISABLE_UPDATE_PNPM_LOCK_ENV]:
	# Force disabled update_pnpm_lock via environment variable. This is useful for some CI use cases.
	should_update_pnpm_lock = False