Non-hermetic dependency on npm_bazel_typescript?

[mprobst]

🐞 bug report

Affected Rule

I suspect something between the WORKSPACE definitions and @npm_bazel_typescript.

Is this a regression?

Unknown.

Description

I'm trying to upgrade tsickle to use the latest version of rules_nodejs, 0.38.0. I've updated my WORKSPACE to include the latest http_archive:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "build_bazel_rules_nodejs",
    sha256 = "1249a60f88e4c0a46d78de06be04d3d41e7421dcfa0c956de65309a7b7ecf6f4",
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/0.38.0/rules_nodejs-0.38.0.tar.gz"],
)

And I've updated package.json (and thus yarn.lock) to depend on bazel 0.29 and @bazel/typescript and @bazel/jasmine in 0.38.0.

After that (and an rm -rf node_modules just to be sure), bazel run @nodejs//:yarn reported an error about having a cyclic dependency:

ERROR: Failed to load Starlark extension '@build_bazel_rules_typescript//:defs.bzl'.                                                                                        
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.                                                                      
The following chain of repository dependencies lead to the missing definition.                                                                                              
 - @build_bazel_rules_typescript                                                                                                                                            
This could either mean you have to add the '@build_bazel_rules_typescript' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive depen
dencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.         

I fixed (?) that by changing the WORKSPACE to load from index.bzl:

# Was: load("@npm_bazel_typescript//:defs.bzl", "ts_setup_workspace")
load("@npm_bazel_typescript//:index.bzl", "ts_setup_workspace")
ts_setup_workspace()

With that in place, I reproducibly received this error:

$ bazel build ...
ERROR: /usr/local/google/home/martinprobst/.cache/bazel/_bazel_martinprobst/1676c3df3a56b0dc61e541b515b67b3c/external/npm_bazel_typescript/index.bzl:20:1: file '@build_bazel
_rules_nodejs//:defs.bzl' does not contain symbol 'COMMON_REPLACEMENTS'
ERROR: /usr/local/google/home/martinprobst/.cache/bazel/_bazel_martinprobst/1676c3df3a56b0dc61e541b515b67b3c/external/npm_bazel_typescript/index.bzl:39:5: Traceback (most re
cent call last):
        File "/usr/local/google/home/martinprobst/.cache/bazel/_bazel_martinprobst/1676c3df3a56b0dc61e541b515b67b3c/external/npm_bazel_typescript/index.bzl", line 38       
                dict(COMMON_REPLACEMENTS, **{"(#|\\/\\/..."})
        File "/usr/local/google/home/martinprobst/.cache/bazel/_bazel_martinprobst/1676c3df3a56b0dc61e541b515b67b3c/external/npm_bazel_typescript/index.bzl", line 39, in dic
t
                COMMON_REPLACEMENTS
global variable 'COMMON_REPLACEMENTS' is referenced before assignment.

After a lot of trial and error, I discovered that npm_bazel_typescript/package.json was actually in 0.33.1.

I was then able to fix the issue by forcefully deleting the entire bazel directory (rm -rf $HOME/.cache/bazel/_bazel_martinprobst/1676c3df3a56b0dc61e541b515b67b3c). bazel clean did not help.

🔬 Minimal Reproduction

Unclear, sorry.

🔥 Exception or Error

See above.

🌍 Your Environment

Operating System:

Linux [...] 4.19.37-5+deb10u2rodete2-amd64 #1 SMP Debian 4.19.37-5+deb10u2rodete2 (2019-08-28 > 2018) x86_64 GNU/Linux

Output of bazel version:

$ ./node_modules/.bin/bazel --version
bazel 0.29.0

Rules version (SHA):

0.38.0 (at least that's the intended version...)

Anything else relevant?

Happy to help with debugging.

[alexeagle]

I think the force delete you did is equivalent to bazel clean --expunge which means delete the external repositories too.

There's a known issue on the upgrade path where Bazel doesn't mark our external repositories like npm_bazel_typescript as dirty after updating package.json, so the stale contents are still there. bazel clean --expunge is the workaround - I'll add that to the release notes.

@gregmagolan was planning to investigate the underlying problem.

[JaredNeil]

I think this is the same thing I was seeing in #1200

Is that the known issue you were referring to? Or is this known earlier?

FWIW, #1205 fixes it for me, but not sure if it's the best solution.

[gregmagolan]

Yup. This looks like a dup of #1200. Was just looking at #1205 and that looks like a good fix.

[surlyengineer]

I'm still seeing this even after #1205 landed

UPDATE: Seems like with the example apps if the yarn install fails with any issue this is the failure that gets generated...