`jest_test` fails to locate test files (when used with `ts_project`?)

[chrisallenlane]

trafficstars

🐞 bug report

Affected Rule

The issue likely pertains to jest_test, and possibly to ts_project.

Is this a regression?

Unknown.

Description

I am encounting surprising behavior when using jest_test with ts_project, and suspect I may have encountered a bug in rules_node.

I am attempting to create a TypeScript monorepo that utilizes jest for testing. I've been modelling my work after the jest examples, though I'm attempting to use ts_project instead of ts_library, as I've read that the former is preferred. With that said, bazel test ... is not performing as expected.

My project builds and runs successfully. However, when I run bazel test ..., jest appears to be unable to locate test files.

I had suspected that this was due to a configuration error on my part. I have discovered, however, that the tests pass when run as follows:

cd bazel-bin/ts/lib/greet && ./ts_greet_test.sh

(ts_greet_test is the name of the test in question.)

Given that the ts_greet_test.sh file is (I believe) machine-generated, can this problem still be a mistake on my part, or may I have encountered an issue with jest_test (and perhaps ts_project)?

🔬 Minimal Reproduction

A minimal reproduction is available here: https://github.com/sharpspring/jest-test-repro

🔥 Exception or Error

Verbose logs are available here: https://gist.github.com/chrisallenlane/1058a1001d1b89032ceecdc5fa89bb7c

🌍 Your Environment

Operating System:

  
ProductName:	Mac OS X
ProductVersion:	10.14.6
BuildVersion:	18G3020
  

Output of bazel version:

  
Build label: 3.7.1-homebrew
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Nov 24 20:20:36 2020 (1606249236)
Build timestamp: 1606249236
Build timestamp as int: 1606249236
  

Rules_nodejs version:

  
2.3.0
  

Anything else relevant? I am relatively new to bazel, and apologize if I've missed anything obvious here.

Thanks very much for your help.

[chrisallenlane]

I noticed something else today. Perhaps this is of diagnostic value:

chrislane@Chris-Lane’s-MacBook-Pro:/Volumes/dev/jest-test-repro/bazel-bin/ts/lib/greet/ts_greet_test.sh.runfiles/com_github_sharpspring_jest_test_repro/ts/lib/greet (fix-attempts)$ ./ts_greet_test.sh
ERROR: cannot find build_bazel_rules_nodejs/third_party/github.com/bazelbuild/bazel/tools/bash/runfiles/runfiles.bash

It seems that ts_greet_test.sh succeeds when run here:

/Volumes/dev/jest-test-repro/bazel-bin/ts/lib/greet/ts_greet_test.sh

But not here:

/Volumes/dev/jest-test-repro/bazel-bin/ts/lib/greet/ts_greet_test.sh.runfiles/com_github_sharpspring_jest_test_repro/ts/lib/greet/ts_greet_test.sh

[chrisallenlane]

It appears that the root cause of the problem is that bazel symlinks test files into a directory for sandboxing, yet jest does not follow symlinks: https://github.com/facebook/jest/issues/1477

Upon making that discovery, my team was able to develop a workaround to the problem: https://github.com/sharpspring/jest-test-repro/pull/1/commits/ef43c7a87fb19144f32d05865453264e33580be1

With that said, I'll leave it to the maintainers' discretion whether or not to close this ticket.

[alexeagle]

That's what this patch is for https://github.com/bazelbuild/rules_nodejs/blob/stable/examples/jest/patches/jest-haste-map%2B24.9.0.patch - do you have this patch included in your repo?

Note we are still hoping Jest will fix it upstream https://github.com/facebook/jest/pull/9351

[chrisallenlane]

Hi, @alexeagle

We did not use that patch for a few reasons:

1. It was not included with the typescript/jest example files, and it was unclear to me if it should be used with TypeScript, or with plain JavaScript only.
2. We were concerned that the patch would be brittle, given that it was written for [email protected], but [email protected] is current.
3. We believe we managed to solve the problem without patching dependencies.

Note we are still hoping Jest will fix it upstream facebook/jest#9351

+1 for this. I do feel that this is best resolved upstream rather than within bazel.

That said, perhaps we could improve the documentation here? I'm willing to work up a PR, if you agree that there is a need.

Either way, our specific problem is now resolved. Feel free to close this ticket if you believe there is no further action necessary.

Thanks very much for your time.

[alexeagle]

yes I'd love a PR against the docs to help prevent another user falling into the same hole.

It was not included with the typescript/jest example files, and it was unclear to me if it should be used with TypeScript, or with plain JavaScript only.

ts is just a subdirectory there, so the package.json and its references should be considered critical to the example yes.

[chrisallenlane]

yes I'd love a PR against the docs to help prevent another user falling into the same hole.

Sounds great. I'll work one up :+1:

[jpoehnelt]

It would be great to have a macro example for typescript.

[github-actions[bot]]

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

[cuyl]

Seems facebook/jest#9351 landed in [email protected], Maybe the patch can be removed in examples?

[github-actions[bot]]

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

[jakeleventhal]

not stale

[github-actions[bot]]

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

[jakeleventhal]

not stale

[gregmagolan]

Jest 27 includes the fix for finding test that as symlinks which is required to work under bazel.

The minimal repo test failure https://github.com/sharpspring/jest-test-repro can be resolved with the following changes:

--- a/jest.config.js
+++ b/jest.config.js
@@ -1,5 +1,9 @@
 module.exports = {
   reporters: ['default'],
   testEnvironment: 'node',
+  haste: {
+    // Required to find test files under bazel runfiles
+    enableSymlinks: true,
+  },
   testMatch: ['**/*.test.js'],
 };
diff --git a/package.json b/package.json
index c1eae64..f309ec5 100644
--- a/package.json
+++ b/package.json
@@ -13,8 +13,8 @@
     "@types/cli-color": "^2.0.0",
     "@types/jest": "^26.0.15",
     "@types/node": "^14.14.9",
-    "jest": "^26.6.3",
-    "jest-cli": "^26.6.3",
+    "jest": "^27.4.3",
+    "jest-cli": "^27.4.3",
     "typescript": "^4.1.2"
   },
   "scripts": {

(plus the corresponding yarn.lock change)

[github-actions[bot]]

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!

[jakeleventhal]

not stale

[alexeagle]

@jakeleventhal can you still repro after upgrading jest and adding the haste config?

[github-actions[bot]]

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!

[jakeleventhal]

not stale

[github-actions[bot]]

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]]

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