Do you want to request a _feature_ or report a _bug_?
Bug
What is the current behavior?
Running jest in monorepo ignores projects in packages.
Minimal repo: https://github.com/deftomat/jest-nested-projects-issue
What is the expected behavior?
Should run all projects in all packages. In another words: Should run nested projects.
Environment
Jest: v22.1.4
Node: v8.9.4
OS: macOS High Sierra
Hey @deftomat
You can also configure jest to run different configurations in different directories, for example, to achieve the desired behavior in your example project, put this as the main jest.config.js file:
module.exports = {
projects: [
{
displayName: "test",
testMatch: ["<rootDir>/packages/**/*.js"]
},
{
displayName: "lint",
runner: "jest-runner-eslint",
testMatch: ["<rootDir>/packages/first/**/*.js"]
}
]
};
If you want to run jest in each repo individually you can use a tool like lerna. Configure a test script in your package.json and use lerna run test to run the test command in each directory.
Whoa, didn't expect such usage to be honest. Projects nested inside other projects, projectception!
It's definitely not a bug, but a lack of feature. We should first discuss if we want projects to be used this way.
I think I'd be happy for this to be supported. We just need to change the project merging to be recursive.
I was under the impression that when a jest root config has projects and you run it, it will actually use a different configuration file/json for each project if the project has one:
E.g.:
// Run jest at the root where the config is {projects: ['<rootDir>/packages/*']}
> jest
// jest will go through each project and find a different config file and use that instead
packages/package-a
jest.config.js
packages/package-b
jest.config.js
Is my assumption wrong?
@rolandjitsu
Well, kind of. We, for example, using TypeScript in a few packages and to make it works, these packages have a necessary config. Global Jest's config doesn't know anything about TS.
So, it looks like Jest is using a package's config, however, it ignores some parts. Like in this issue, it ignores projects properties and also, as mentioned here, it ignores global setup/teardown.
Jest is awesome and probably the best test framework but _projects_ feature is highly unpredictable. At least, for me 馃槈
When i do something similar to this:
module.exports = {
projects: [
{
displayName: "test",
testMatch: ["<rootDir>/packages/**/*.js"]
},
{
displayName: "lint",
runner: "jest-runner-eslint",
testMatch: ["<rootDir>/packages/first/**/*.js"]
}
]
};
in my own package with the exception of using multiple runners (i'm interested in running tests in multiple projects from the root dir), jest runs matching every single file in the entire repo. It also applies the babel version of root instead of using each packages
@brad-decker as a workaround for a related problem I have created fork of babel-jest. Please let me know if this works for you: https://github.com/lehni/babel-jest-nested
There is also a pending PR to get this merged into babel-jest that I am hoping will get some attention: https://github.com/facebook/jest/issues/6617
@cpojer @thymikee This is an old one but is there still interest in supporting nested projects?
My specific use case is a monorepo with a structure like:
apps
- app-one
- jest.config.json
- app-two
- jest.config.json
packages
- shared-package # used in both apps
- jest.config.json
- design-system # used in both apps
- jest.config.json
- utils # use in app-one and shared-package (transitive dep of app-two via shared-package)
- jest.config.json
We are wanting to have our apps each define jest.config.json with projects set to include all local dependencies of the app. This would allow us to test the app and any direct/transitive dependencies.
I'd be fine to take on the work but might need somebody to point me in the direction of Jest's config resolution code.
I would very much like this feature as well.
@nathanforce the code in question looks to be here: https://github.com/facebook/jest/blob/aa64672e728738926571746a85c57d1658bdaf55/packages/jest-config/src/index.ts#L280
It appears to be taking the project list from the command line args or top level projects array, but doesn't expand this array with subprojects.
Still happy to merge a PR with this. Link above is a good start - recursively going through all globalConfig.projects until they're empty arrays seems like it should work?
Most helpful comment
I think I'd be happy for this to be supported. We just need to change the project merging to be recursive.