Jest 24 seems to also run a top level test despite having projects set in package.json

[Jessidhia]

💥 Regression Report

A clear and concise description of what the regression is.

Last working version

Worked up to version: 23.6

Stopped working in version: 24

To Reproduce

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

Expected behavior

Jest should only run tests for the given projects.

Run npx envinfo --preset jest

Paste 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

[jeysal]

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 :)

[victorandree]

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 jest@23.6.0 (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.

[SimenB]

A single project is buggy, see #7496

[victorandree]

Ok, I see. I updated master to have multiple projects and now it works as expected. 🙃

[migueloller]

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.

[martijnwalraven]

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

[migueloller]

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

[freshollie]

I have a reproduction repo showing these issues: https://github.com/freshollie/jest-7733

[SimenB]

That seems expected - jest works by walking up the FS until it finds config. We could maybe do something more clever here?

[freshollie]

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.

[gdlm91]

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'],
};

[seawatts]

@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

[gdlm91]

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

[seawatts]

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

[AndrewSouthpaw]

@seawatts's setup worked for me as well. My mistake from before was that I was not splitting out the "root config" from the "base config", and then accidentally bringing in projects to each module-level config. So my wrong config was like this:

// jest.config.js
module.exports = {
  projects: ['modules/*/jest.config.ts', './jest.config.js']
  // other stuff
}

// module/package/jest.config.ts
const baseConfig = require('../../jest.config')
export default {
  ...baseConfig, // this also set projects at module level, which seriously confused jest
  // other stuff
}

Note that running

$ cd ./modules/package
$ jest

only works if you also have jest installed at that module level. We don't (to keep versioning simple, and have only one instance of Jest, I'm worried we end up requiring multiple Jest packages otherwise), so we need to do something more obtuse:

$ cd ./modules/package
$ ../../node_modules/.bin/jest

Not great, but gets the job done.

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

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.

[github-actions]

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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.