[Bug]: Jest ignores near all files on Windows with GNU find

[Roukanken42]

Version

29.7.0

Steps to reproduce

1. Be on Windows system
2. Ensure where find points to a GNU find with -iname (for example ezwinports has x32 or x64)
3. Clone minimal reproduction repo at https://github.com/Roukanken42/jest-find-bug
4. npm install
5. npm test

Expected behavior

I expect to see the test add.test.js run and succeed

Actual behavior

Jest instead doesn't find the test, and regardless of the number of files in the project, it will always proclaim that it only checked one file. Example output:

No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In D:\Projects\temp\jest-find-bug
  1 file checked.
  testMatch: **/__tests__/**/*.[jt]s?(x), **/?(*.)+(spec|test).[tj]s?(x) - 0 matches
  testPathIgnorePatterns: \\node_modules\\ - 1 match
  testRegex:  - 0 matches
Pattern:  - 0 matches

Additional context

I did some debugging, and this happens because of two things:

A GNU find needs to be on the path, so the call find . ( -iname *.ts -o -iname *.js ) succeeds. One such find is from ezwinports findutils. Example output from it is:

λ find . ( -iname *.ts -o -iname *.js )
./add.js
./add.test.js
./jest.config.js
./node_modules/@ampproject/remapping/dist/remapping.umd.js
./node_modules/@ampproject/remapping/dist/types/build-source-map-tree.d.ts
./node_modules/@ampproject/remapping/dist/types/remapping.d.ts
./node_modules/@ampproject/remapping/dist/types/source-map-tree.d.ts
./node_modules/@ampproject/remapping/dist/types/source-map.d.ts
./node_modules/@ampproject/remapping/dist/types/types.d.ts
[...more lines]

Note that this output has lines separated by \r\n and not just \n

Secondly, in jest config, haste must be set to something, otherwise it will use default true for its property forceNodeFilesystemAPI. However, this behavior will end, even with config such as module.exports = {haste: {}}, as is used in the minimal reproduction. (instead, it will get undefined as a value, which is then later coerced into false)

This means that some presets for jest can trigger this behavior unintentionally, while setting other properties. For example, jest-expo sets platforms and defaultPlatform by default. In a fresh setup, this was computed to

haste: {
  defaultPlatform: 'ios',
  platforms: [ 'android', 'ios', 'native' ]
}

Both this issues combine, into triggering findNative while crawling, which will call find subprocess, but its output will be unexpected. For example, contents of lines array will all except last one have trailing carriage return on them, and will mix \ & / for paths. While the second is not issue for Windows per-se, it causes some issues with the HasteMap implementation down the line. Trimming the lines, and replacing / with \ makes the code work properly.

[
  'D:\\Projects\\temp\\jest-find-bug/add.js\r',
  'D:\\Projects\\temp\\jest-find-bug/add.test.js\r',
  'D:\\Projects\\temp\\jest-find-bug/jest.config.js\r',
  'D:\\Projects\\temp\\jest-find-bug/node_modules/.package-lock.json\r',
  'D:\\Projects\\temp\\jest-find-bug/node_modules/@ampproject/remapping/dist/remapping.mjs\r',
  'D:\\Projects\\temp\\jest-find-bug/node_modules/@ampproject/remapping/dist/remapping.umd.js\r',
  'D:\\Projects\\temp\\jest-find-bug/node_modules/@ampproject/remapping/dist/types/build-source-map-tree.d.ts\r',
  'D:\\Projects\\temp\\jest-find-bug/node_modules/@ampproject/remapping/dist/types/remapping.d.ts\r',
  'D:\\Projects\\temp\\jest-find-bug/node_modules/@ampproject/remapping/dist/types/source-map-tree.d.ts\r',
  ...
]

Environment

System:
    OS: Windows 11 10.0.22631
    CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor
  Binaries:
    Node: 18.20.3 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - c:\program files (x86)\yarn\bin\yarn.CMD
    npm: 10.7.0 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    jest: ^29.7.0 => 29.7.0

[SimenB]

I wonder if we should just ditch shelling out to find always. Crawling in JS is way faster (as long as ignores are sane, which they usually are).

---

I don't have a windows system to debug with, unfortunately 😕 But changing the code to handle newline and optional carriage return might make sense? Would that help? If so, wanna send a PR for it?

[Roukanken42]

Sadly, just trimming the carriage returns doesn't work, it causes some issue down the line, something with path handling from the output. If I just changed the find output handling to something that can optionally handle carriage returns, like this:

const lines = stdout
  .trim()
  .split('\n')
  .map(line => line.replace(/\r$/g, ''))
  .filter(x => !ignore(x));

It'll trigger haste module naming collisions:

jest-haste-map: Haste module naming collision: @bcoe/v8-coverage
  The following files share their name; please adjust your hasteImpl:
    * <rootDir>\node_modules\@bcoe\v8-coverage\dist\lib\package.json
    * <rootDir>\node_modules\@bcoe\v8-coverage\package.json

jest-haste-map: Haste module naming collision: ansi-styles
  The following files share their name; please adjust your hasteImpl:
    * <rootDir>\node_modules\@babel\highlight\node_modules\ansi-styles\package.json
    * <rootDir>\node_modules\ansi-styles\package.json

jest-haste-map: Haste module naming collision: chalk
  The following files share their name; please adjust your hasteImpl:
    * <rootDir>\node_modules\@babel\highlight\node_modules\chalk\package.json
    * <rootDir>\node_modules\chalk\package.json

jest-haste-map: Haste module naming collision: color-convert
  The following files share their name; please adjust your hasteImpl:
    * <rootDir>\node_modules\@babel\highlight\node_modules\color-convert\package.json
    * <rootDir>\node_modules\color-convert\package.json

This is most likely caused by the mixed slashes in the the paths (as the find puts out forwards slashes, but they are joined with <rootDir> which has backwards slashes). Paths like this are in fact valid Windows paths, so it likely has to happen while analysing them in js somewhere. If I also change all the slashes to backwards slashes (via .map(line => line.replace(/\//g, '\\'))), the test will run fine, but that would ofc have to be conditioned on the os, (and I think it's not safe to do it dumbly like this anyway)

I haven't investigated further than that though, so unsure if that is all that's needed...

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.