Do you want to request a _feature_ or report a _bug_?
bug
What is the current behavior?
A CLI run which worked before (22.0.4):
jest --coverage "--collectCoverageFrom=src/**/*" "--collectCoverageFrom=!src/pages/**/*" "--collectCoverageFrom=!src/ui/**/*" "conf" "tools" "src/base" "src/features" "src/routes" "src/services" "src/pages/export/" "src/pages/renderer/"
running tests from conf, tools, src/base, ...
now fails in 22.0.5:
jest --coverage "--collectCoverageFrom=src/**/*" "--collectCoverageFrom=!src/pages/**/*" "--collectCoverageFrom=!src/ui/**/*" "conf" "tools" "src/base" "src/features" "src/routes" "src/services" "src/pages/export/" "src/pages/renderer/"
--
| FAIL ./conf
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
|
| FAIL ./tools
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
|
| FAIL src/base
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
|
| FAIL src/features
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
|
| FAIL src/routes
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
|
| FAIL src/services
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
|
| FAIL src/pages/export
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
|
| FAIL src/pages/renderer
| ● Test suite failed to run
|
| EISDIR: illegal operation on a directory, read
|
| at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.
repl.it is at 20.0.4 and won't have the same problem.
Repository is here: https://github.com/joscha/jest-2205-folders
What is the expected behavior?
The tests are run.
Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.
node v8.9.4
jest 22.0.5
yarn 0.27.5
OSX Sierra but also fails on CI which is a Linux
Could potentially be related to a yargs, given that conf and tools seem to be picked up differently than the other arguments (note leading ./) - hunch comes from https://github.com/webpack/webpack-dev-server/issues/1259#issuecomment-356243604
toying around with the changes a bit, it seems as if the problem is somewhere in a transitive jest dependency - installing a fixed [email protected] still brings jest-cli 22.0.5, etc. and the problem persists.
Looks like a problem with #3793 and PR #3882.
cc @valerybugakov
@joscha as a workaround, if you use yarn you can use resolutions to lock down a dependency down the chain
For cross-reference, I've suggested changes in this comment on #3793 and would appreciate feedback. It's a great issue for anyone looking to contribute. I'll have a go later this week if I find some "spare" time.
Just for extra context to support we've encountered this bumping up from jest v21.
- "babel-jest": "^21.0.0",
+ "babel-jest": "^22.0.6",
- "jest": "^21.0.0",
+ "jest": "^22.0.6",
We pass a directory (/src) into our jest command. This fails both locally and in our ci environment (circleci).
There is a single output of the following error message:
Test suite failed to run
EISDIR: illegal operation on a directory, read
at Error (native)
at Object.readSync (node_modules/graceful-fs/polyfills.js:138:28)
I had to downgrade to the following jest packages:
"babel-jest": "^21.2.0",
"jest": "^21.2.1",
"jest-cli": "^21.2.1",
If your tests are in a directory e.g. test, you can work around this by invoking jest test/**/*.js instead of jest test.
Perhaps it should be documented more explicitly that it's required to pass a glob pattern that matches test files rather than specifying a test directory, assuming it will recursively search that directory for test files.
The directory not being picked up is a regression and wouldn't need to be documented.
The PR that introduced the change, #3882, did add a bit of a twist to the file matching though. If a file exists it will be considered a test, regardless if it matches the testMatch pattern(s).
If your tests are in a directory e.g. test, you can work around this by invoking jest test/*/.js instead of jest test.
yes, although the import pattern is different for each project and it would be quite a chore to add it - we pick up folders vaild for tests with a glob in bash, e.g. the non-simpliefied invocation of jest looks like this:
shopt -s extglob
yarn jest -- \
--collectCoverageFrom='src/**/*' \
--collectCoverageFrom='!src/pages/**/*' \
--collectCoverageFrom='!src/ui/**/*' \
conf tools src/!(pages|ui) src/pages/!(editor|templates)/
ideally I would not need to post-process:
conf tools src/!(pages|ui) src/pages/!(editor|templates)/
and add every pattern in jestconfig.testMatch to it (plus any permutation).
I will do it, if this "change" (which is a regression in my eyes), is the new default, but I'd hope we find a fix for this behaviour instead.
I too am receiving this error now with 22.0.6. Was doing...
jest src
Now I am using this workaround:
jest --testPathPattern src
If it helps anyone else...
Most helpful comment
I too am receiving this error now with
22.0.6. Was doing...Now I am using this workaround:
If it helps anyone else...