Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node process.domain behavior broken when running code using Jest #7247

Closed
harelmo opened this issue Oct 23, 2018 · 6 comments 路 Fixed by #9136
Closed

Node process.domain behavior broken when running code using Jest #7247

harelmo opened this issue Oct 23, 2018 · 6 comments 路 Fixed by #9136

Comments

@harelmo
Copy link
Contributor

harelmo commented Oct 23, 2018

馃悰 Bug Report

Jest seems to modify the process object in such a way that breaks the ability to run code inside a domain - i.e., process.domain does not change to be the current domain set by calling the enter() method of a domain or running an arbitrary code through the run() method.

  • I know this feature is deprecated in node, yet we still have some production-code using it heavily - so suggestions to stop using this modules are unfortunately invaluable at the moment.

To Reproduce

Steps to reproduce the behavior:

Run jest with the following spec file (not setup or actual production-code required):

const domain = require('domain')

describe('node domain', () => {
  test('should show that the current domain is used when running a function using domain.run(...)', () => {
    const d = domain.create()
      
    d.run(() => {
        expect(process.domain).not.toBeNull()
    })
  })
})

Expected behavior

The test above should pass, since process.domain should be set to the actual domain object in which the code is being run. See https://nodejs.org/docs/latest-v8.x/api/domain.html#domain_domain_enter.

Running the test in mocha + chai (with the relevant changes to the test only - requiring expect from chai and changing the matcher to not.to.be.null) results in a passing test.

Link to repl or repo

https://repl.it/@HarelMoshe/testNodeDomains

Output from npx envinfo --preset jest:

 System:
    OS: macOS High Sierra 10.13.2
    CPU: x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
  Binaries:
    Node: 8.12.0 - ~/.nvm/versions/node/v8.12.0/bin/node
    Yarn: 1.6.0 - /usr/local/bin/yarn
    npm: 5.10.0 - ~/.nvm/versions/node/v8.12.0/bin/npm
  npmPackages:
    jest: ^23.6.0 => 23.6.0
@SimenB
Copy link
Member

SimenB commented Oct 23, 2018

I doubt we'll spend time implementing support for domains in Jest seeing as it's deprecated. However, if the diff is minimal, a PR is of course welcome 馃檪 The process object is created here: https://github.com/facebook/jest/blob/5eb9d36687d01059570182c4f33fef6e431dbaf5/packages/jest-util/src/create_process_object.js

@harelmo
Copy link
Contributor Author

harelmo commented Oct 24, 2018

Thanks for pointing me to that code @SimenB - it actually made me think about a workaround to make the process object have the domain-related code attached to it prior to Jest performing the copy.
All I had to do is create a global-setup file exporting the following:

test/setup/global-setup.js:

module.exports = () => { require('domain') }

and use it as the global-setup file in my jest.config.js file:

module.exports = {
  globalSetup: `test/setup/global-setup.js`
}

Since require-ing the domain module has the side-effect on process in the global-setup phase - i.e., prior to Jest making its copy - that logic is persisted to the copy and everything seems to work fine.

@harelmo harelmo closed this as completed Oct 24, 2018
idan-at pushed a commit to idan-at/jest that referenced this issue Nov 5, 2019
Fixes jestjs#7247: Explicitly copy domain to new process
@SimenB
Copy link
Member

SimenB commented Nov 11, 2019

For anyone subscribed: should be fixed in #9136 which will come in Jest 25

@mapleeit
Copy link
Contributor

Hi, @SimenB . Could you update jest@next on npm? Seems it's still a version published 3 months ago.

@mapleeit
Copy link
Contributor

ping @SimenB

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants