-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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]: Jest ignores near all files on Windows with GNU find #15097
Comments
I wonder if we should just ditch shelling out to 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? |
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 const lines = stdout
.trim()
.split('\n')
.map(line => line.replace(/\r$/g, ''))
.filter(x => !ignore(x)); It'll trigger haste module naming collisions:
This is most likely caused by the mixed slashes in the the paths (as the I haven't investigated further than that though, so unsure if that is all that's needed... |
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. |
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. |
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. |
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. |
Version
29.7.0
Steps to reproduce
where find
points to a GNU find with-iname
(for example ezwinports has x32 or x64)npm install
npm test
Expected behavior
I expect to see the test
add.test.js
run and succeedActual 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:
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: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 defaulttrue
for its propertyforceNodeFilesystemAPI
. However, this behavior will end, even with config such asmodule.exports = {haste: {}}
, as is used in the minimal reproduction. (instead, it will getundefined
as a value, which is then later coerced intofalse
)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 toBoth this issues combine, into triggering
findNative
while crawling, which will callfind
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.Environment
The text was updated successfully, but these errors were encountered: