Jest projects do not inherit root/global config

🐛 Bug Report

This isn’t mentioned anywhere in the docs, so I’m not entirely sure how this is supposed to work. But I have a monorepo (yarn workspaces) and I want some packages to have expanded Jest configs, while all of them to inherit “common” configs. I assumed that any settings in the root jest.config.js would be inherited for all project configs, but this does not seem to be the case, and is honestly very tedious to work around.

If I have this root config:

module.exports = {
  projects: ['packages/*'],
  setupFilesAfterEnv: ['<rootDir>/tests/setup.ts'],
};

I would expect all projects to inherit the setupFilesAfterEnv setting, but they do not. According to --showConfig, it’s just an empty array. How else are we supposed to share config without having to create a jest.config.js in each project?

To Reproduce

Steps to reproduce the behavior:

Mentioned above.

Expected behavior

Projects would inherit the root/global config.

Link to repl or repo (highly encouraged)

envinfo

npx envinfo --preset jest

  System:
    OS: macOS 10.15.7
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v12.18.3/bin/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.3/bin/npm

[Rossh87]

@manchuck I probably shouldn’t have tried to speak to the authors’ intentions, since I’m not a maintainer. What I mean is just that I can imagine root config-sharing by default leading to confusion or slowing down tests a lot for monorepos whose projects have very different external dependencies (databases, servers, etc.) that need to be setup for tests. For example, if I have a client module and a server module in a monorepo that represents all the code for some website, I might want to spin up a real database for integration testing the server, but probably won’t need it for testing the client. If the database setup ended up in the root config, I’d be needlessly spinning up a database every time I ran the client test suite, which isn’t ideal. Conceptually, my impression is that workspaces are intended to be autonomous, and sharing setup creates implicit dependency, which isn’t ideal IMO. I do see your point, though, and it’s perfectly reasonable to disagree.

Depending on your specific case, you could try extracting your custom assertion library into its own workspace, turning it into a discrete package that your other workspaces can explicitly depend on by importing it. That’s what I would personally prefer for a custom assertion library, but YMMV.

[manchuck]

@Rossh87 seems strange that this is working as intended. I have a file that adds custom expect assertions that all projects are using. This means I have to copy over setupFilesAfterEnv into each project. Sure it is easy enough to spread it out when using jest.config.js however using package.json can lead to typos and make it annoying to change. There has to be some easier way to set this up