A clear and concise description of what the regression is.
Worked up to version: 23.6
Stopped working in version: 24
I am not sure if this is completely consistent, but; given a monorepo where the top level package.json jest config is just:
"jest": {
"projects": [
"packages/@*/*",
"app/"
]
}
and there is otherwise no top level config (all config is inside monorepo packages), jest seems to run an independent instance on the top level that will likely fail to build anything due to not finding the necessary config nested inside (for example, the transform config, or the moduleNameMapper).
This seems related to https://github.com/facebook/jest/issues/7268.
Directly using the --projects option in the command line prevents this top level configless runner from running, but --projects itself does not accept globs.
Manually enumerating each possible package with an additional --projects per package (--projects foo --projects bar --projects bar, etc) also behaves correctly. It's only loading the projects config from package.json that seems to be broken.
I could tell that there were two runners when I tried giving the path to a test file as an argument -- for example, jest app/foo/foo.test.js. There would be _two_ status lines printed for the same file, one would FAIL due to missing config, the other would PASS.
Jest should only run tests for the given projects.
npx envinfo --preset jestPaste the results here:
System:
OS: macOS 10.14.3
CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
Binaries:
Node: 11.8.0 - ~/.nodenv/versions/11.8.0/bin/node
Yarn: 1.14.0 - ~/.nodenv/versions/11.8.0/bin/yarn
npm: 6.5.0 - ~/.nodenv/versions/11.8.0/bin/npm
npmPackages:
jest: ^24.0.0 => 24.0.0
I could not reproduce this by creating the minimal package/directory structure to match your description - Jest only ran on packages/@a/a, packages/@a/b, and app.
Please provide a repository to reproduce this :)
I want to hijack this issue, because I've run into the same problem (I think?). My reproduction repository is here: https://github.com/victorandree/jest-7733
For me, this also doesn't work with [email protected] (see https://github.com/victorandree/jest-7733/tree/jest23).
Maybe this isn't _expected_ behavior but I can't understand what the point of projects is in that case? Without --projects, running jest seems to run tests ignoring the projects setting in its configuration.
A single project is buggy, see #7496
Ok, I see. I updated master to have multiple projects and now it works as expected. 馃檭
I have this issue as well, here's my Jest config:
const Config = {
projects: ['<rootDir>/packages/*'],
}
module.exports = Config
To get around it I can't just add '<rootDir>/packages/some-package' as I get the following error:
Error: Whoops! Two projects resolved to the same config path: packages/some-package/jest.config.js
As a workaround, I can enumerate each package individually but that's quite verbose and brittle.
@SimenB We encountered a similar issue and tracked it down to an empty leftover directory that matched the projects pattern. Apparently, a pattern like projects: ['<rootDir>/packages/*'] and an empty <rootDir>/packages/some-package will lead to the creation of an additional top-level project with default config. In our case, that meant all test suites in all packages were running twice, but the top-level instances all failed because ts-jest wasn't configured.
@martijnwalraven,
This was exactly what happened to us! Thanks for sharing the repro. I was able to go back to using projects: ['<rootDir>/packages/*'] instead of having to specify each package manually.
I have a reproduction repo showing these issues: https://github.com/freshollie/jest-7733
That seems expected - jest works by walking up the FS until it finds config. We could maybe do something more clever here?
Is there any reason jest can't ignore files which are not already being run under projects? It seems very not obvious when you have test files being run twice.
Edit:
If jest is being run from the root, could it not just ignore any folders going down the directory structure which contain some sort of jest.config? Does this break anyones workflow? This could just come into effect if a "projects" option has been specified? I can't see why anyone would want to run jest from the root of the repo and inside the projects specified.
I was having a similar issue with Jest running the test in each package AND also form the root of the monorepo.
Changing my projects config to specify the Jest configuration of each package solve it. Ex:
module.exports = {
// specifying the jest configuration of each package will force Jest to NOT run test from Root too,
// but instead just run tests in packages and use root as the folder to dump the coverage report
projects: ['<rootDir>/packages/*/jest.config.js'],
};
@gdlm91 I tried that and I am still seeing the same thing happen where it will run everything from the top level. I put a console.log statement in the sub package jest.config.js and it is not even being run. However, if I run it from the cli and set the --projects flag then it works.
e.x.
jest --projects packages/sub-project/jest.config.js
@seawatts , I took @freshollie repo and applied the fix I mentioned, and seems to work fine. You can check it out here: https://github.com/gdlm91/jest-7733
Or I might be missing the real problem...
Thanks @gdlm91 I also got it working as well I think what got it working for me was adding
// ./jest.config.js
const baseConfig = require('./jest.config.base');
module.exports = {
...baseConfig,
projects: ['<rootDir>/packages/*/jest.config.js'],
};
// ./jest.config.base.js
module.exports = {
...{your other props},
testMatch: [`<rootDir>/src/**/*.test.{ts,tsx}`],
collectCoverageFrom: [`<rootDir>/src/**/*.{ts,tsx}`],
}
and then in each sub directory I just have
// ./packages/sub-project/jest.config.js
const base = require('../../jest.config.base');
module.exports = {
...base,
displayName: 'My Sub Directory'
}
This allows me to run jest at the top level as well as in each sub directory. e.x.
# base directory
$ jest # Runs all tests in every project and stores coverage data in `./coverage`
# -- OR --
$ cd ./packages/sub-project
$ jest # Only runs sub-project tests and stores coverage in `./packages/sub-project/coverage
Most helpful comment
@seawatts , I took @freshollie repo and applied the fix I mentioned, and seems to work fine. You can check it out here: https://github.com/gdlm91/jest-7733
Or I might be missing the real problem...