Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: No tests detected on Windows #270

Open
ahmedneilhussain opened this issue Apr 25, 2024 · 3 comments
Open

[Bug]: No tests detected on Windows #270

ahmedneilhussain opened this issue Apr 25, 2024 · 3 comments
Labels
bug Something isn't working untriaged Requires traige

Comments

@ahmedneilhussain
Copy link

What happened?

I've been trying to get some simple unit tests working with rules_jest: it's been fine on Linux and OSX, but the rules fail on Windows: I just get

No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
No files found in C:\Users\vagrant\_bazel_vagrant\x57pwzg3\execroot\_main\bazel-out\x64_windows-fastbuild\bin\src\src_test.bat.runfiles\_main\src

and variations on that theme. After struggling with my own examples, I tried to just run the example at https://github.com/aspect-build/bazel-examples/tree/main/jest

This showed the same problem.

Version

Development (host) and target OS/architectures:
Windows 10 Pro

Output of bazel --version:

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

Language(s) and/or frameworks involved:

How to reproduce

Just run `bazel run //src:src_test` on windows against https://github.com/aspect-build/bazel-examples/tree/main/jest

Any other information?

I had to struggle to get it the example project to build (I needed to disable hooks for two npm dependencies), and also had some issues because the split code/test ts_project targets run into the known issue with the sources from one being picked up by the other (I got a lot of file permissions errors when the test compile target tried to produce the same outputs as the source compile target; however even when I changed it to have a single compilation ts_project the test target failed to run).

I've tried setting patch_node_fs = False (had some problems with test rules on windows before and this seemed to fix it) but didn't seem to help.

The run files tree looks fine - the source and test js files are all output OK as they are on other platforms. I've even added some code to my jest.config.js to write some output to a file with the result of calling glob.sync('**/*.js') and that picks the files up OK, so they are visible to node...

@ahmedneilhussain ahmedneilhussain added the bug Something isn't working label Apr 25, 2024
@github-actions github-actions bot added the untriaged Requires traige label Apr 25, 2024
@ahmedneilhussain
Copy link
Author

ahmedneilhussain commented Apr 29, 2024

It looks to be an issue with Jest not liking symlinks, or particularly leaf symlinks. Others have raised issues with bazel + jest before because of this, see jestjs/jest#5356 . This presumably predates rules_jest however. On my setup, Bazel 7.1.0 and jest 29.7.0, it worked out of the box on Linux and MacOS but fell over on Windows.

I thought it might have been a / \ path canonicalisation issue, so experimented with increasingly permissive test regex/glob patterns, but it made no difference. However I discovered that if I hacked the run files on my Windows setup and added a real .js file rather than a symlink to one, it was picked up.

As discussed in the Jest issue linked above, it is down to the file crawler in jest-haste-map. It tries to shell out to find if that utility is present, which it is on MacOS and Linux. On Windows, or if --forceNodeFilesystemAPI is true (see https://jestjs.io/docs/configuration#haste-object), it crawls the filesystem itself using the Node APIs, and explicitly skips symbolic links (or at least leaf files that are symbolic links). Note that Jest and Node can read the contents of files referenced by symlinks just fine, it's just that without the files being found in the initial crawl, they never get matched: this is why it works so long as find is present.

I found that applying the following patch (using the pnpm patching mechanism) to jest-haste-map made it work on Windows:

diff --git a/build/crawlers/node.js b/build/crawlers/node.js
index eb90b4e1bce64ab6809d914db9122e1fc8dc151c..e78d3f810f5629d6f9e90d870a162f4b8d59ec60 100644
--- a/build/crawlers/node.js
+++ b/build/crawlers/node.js
@@ -133,9 +133,9 @@ function find(roots, extensions, ignore, enableSymlinks, callback) {
           if (ignore(file)) {
             return;
           }
-          if (entry.isSymbolicLink()) {
-            return;
-          }
+          // if (entry.isSymbolicLink()) {
+          //   return;
+          // }
           if (entry.isDirectory()) {
             search(file);
             return;

@ahmedneilhussain
Copy link
Author

It looks from your build hooks as though you have builds running and passing tests on Windows, but I don't understand how they could unless a port of find is present in the environment..? I wondered if there was a Bazel flag (or older Bazel behaviour) that could construct the runfiles with full copies rather than links, but couldn't spot anything on skimming the docs.

@ahmedneilhussain
Copy link
Author

Incidentally

config.haste = { enableSymlinks: true };
should perhaps use ??= rather than = so that other haste options are not overwritten/ignored..?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working untriaged Requires traige
Projects
None yet
Development

No branches or pull requests

1 participant