[Bug]: Jest ignores near all files on Windows with GNU find about jest HOT 3 OPEN

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?

from jest.

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

from jest.

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.

from jest.