globalSetup and globalTeardown are ignored in projects.

[deftomat]

Do you want to request a feature or report a bug?
Bug.

What is the current behavior?
globalSetup and globalTeardown are ignored when they are defined inside a project.

If the current behavior is a bug, please provide the steps to reproduce
I'm using the following jest.config.js:

module.exports = {
  projects: [
    {
      displayName: 'unit',
      testMatch: ['<rootDir>/src/**/*.spec.ts'],
      transform: {
        "^.+\\.ts$": "ts-jest"
      },
      moduleDirectories: ["node_modules", "./"],
      moduleFileExtensions: ["ts", "js", "json", "node"]
    },
    {
      displayName: 'e2e',
      testMatch: ['<rootDir>/e2e/**/*.spec.ts'],
      transform: {
        "^.+\\.ts$": "ts-jest"
      },
      moduleDirectories: ["node_modules", "./"],
      moduleFileExtensions: ["ts", "js", "json", "node"],
      globalSetup: '<rootDir>/e2e/global-setup.js',
      globalTeardown: '<rootDir>/e2e/global-teardown.js'
    }
  ]
};

What is the expected behavior?
I'm not sure if this is an expected behaviour or not. However, whey I try to use a non-existing file for a globalSetup / globalTeardown, then it throws the following error:

Validation Error:
Module .../e2e/global-setup.js in the globalSetup option was not found.

So, Jest is expecting an option like this in project.

Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.
Jest: v22.1.4
Node: v8.9.4
OS: macOS High Sierra

[thymikee]

Can you please provide a repro which we can clone and run?

[deftomat]

@thymikee Sure, see https://github.com/deftomat/jest-global-setup-issue.

Expected behaviour:
Global Setup/ Global Teardown should create a new files in root of this project.

Instead, they are ignored. It works only when you move them outside of e2e project.

[deftomat]

Also, I find out that globalSetup and globalTeardown are ignored when you use jest --projects packages/foo in yarn workspaces. Even when setup and teardown from foo package are not wrapped in "projects" property.

So, basically the same error: setup and teardown are ignored if they are required by project. Using a jest --projects is just another way how to "wrap" them into a project.

In another words: globalSetup and globalTeardown in any package are ignored when you try to run jest on multiple packages using --projects flag.

[goodmind]

any updates?

[t-kelly]

Also having this problem when trying to run some test files with jest-puppeteer, and other test files with jsdom. Any workarounds?

[SimenB]

This is not specific to globalSetup and globalTeardown, it's for any global config (as opposed to project config). They have to be at the top level. I'm not sure if we should explicitly throw, or try to hoist them so they work. What about if multiple projects has the same configs?

[thymikee]

@SimenB we also have some older issue with the same problem: #5938. Let's move the discussion here

[ctrlplusb]

Sorry to spam this thread, but was wondering if anyone had come up with a workaround? I spin up some in memory mock stores etc, which are only applicable to certain projects within my monorepo. Ideally I'd like some mechanism of controlling the resources per project.

[ranyitz]

@ctrlplusb If I understand correctly you'd like to run only the relevant globalSetup/globalTeardown according to the tests that you're going to run at the moment.

A workaround would be to create a top-level globalSetup and globalTeardown that do different things (or call other globalSetup files) according to the tests that should be run. You'll get jest's globalConfig as a parameter and could use values from it against each project's testMatch/testRegex. I know it's not a perfect solution but it might just do the trick.

---

I think a good solution would be to run a project's globalSetup file only if we run at list one test from this project. So devs could write setup code that relates to a certain type of tests. For example, you don't need to bootstrap puppeteer if you don't have any e2e test to run at the moment.

[shellandbull]

@ranyitz thanks for your comment, would be great to see a working example of a monorepo with that 😄

[ranyitz]

@mariogintili I started implementing the hacky way to do that, realizing it would be fairly easy to implement properly in Jest. We can call it projectSetup/projectTeardown, it would work like globalSetup/globalTeardown for a specific project.

Here an example:

Some use the projects feature for running different environments/runners in the same module while other for multiple modules in a monorepo. Maybe we can stick with the names globalSetup/globalTeardown which will work as displayed above?

@thymikee @SimenB what do you think?

[SimenB]

Happy to review a PR, but no guarantees it'll be merged 🙂 I like the idea, though!

[ranyitz]

@SimenB Thanks, sounds fair 👍
I'll create a PR soon.

[smeijer]

A workaround would be to create a top-level globalSetup and globalTeardown that do different things (or call other globalSetup files) according to the tests that should be run. You'll get jest's globalConfig as a parameter and could use values from it against each project's testMatch/testRegex. I know it's not a perfect solution but it might just do the trick.

I inspected the globalConfig argument, but how can I see what the current (running) project is?

I need to be able to start the mongodb-memory-server only for the integration tests. Not for running unit tests. I thought having a project for integration tests and one for unit tests, with both their own testEnvironment with corresponding setup and teardown scripts, would be able to provide this for me. But if I understand correctly, that's currently not possible.

[ranyitz]

@smeijer That's correct, there is no (proper) way to see the current running project.
I've been working on #6865 which supports your use case.

[SimenB]

#6865