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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setSystemTime and getRealSystemTime always throw if yarn/npm does not deduplicate @jest/fake-timers #11662

Closed
simon-paris opened this issue Jul 14, 2021 · 4 comments · Fixed by #11946

Comments

@simon-paris
Copy link

simon-paris commented Jul 14, 2021

🐛 Bug Report

Jest relies on yarn/npm to deduplicate @jest/fake-timers. If it is not deduplicated, the following functions always throw the error setSystemTime is not available when not using modern/legacy timers.

  • setSystemTime
  • getRealSystemTime
  • runAllImmediates

It's caused by the instanceof checks in this file: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.ts.

I've attached my real yarn lock file to prove that deduplication can fail in the wild, and not just in the contrived example below. yarn.lock.zip

To Reproduce

Run the following

yarn add [email protected] @jest/[email protected]
echo "jest.useFakeTimers('modern').setSystemTime(new Date());" > test.js
yarn jest

It will output this:

 FAIL  ./test.js
  ● Test suite failed to run

    TypeError: setSystemTime is not available when not using modern timers

    > 1 | jest.useFakeTimers('modern').setSystemTime(new Date());
        | ^
      2 |

      at Object.setSystemTime (node_modules/jest-runtime/build/index.js:1989:17)
      at Object.<anonymous> (test.js:1:1)

Expected behavior

Jest should not rely on yarn/npm deduplication behavior.

Link to repl or repo (highly encouraged)

Just run the script above in an empty folder.

envinfo

  System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-8569U CPU @ 2.80GHz
  Binaries:
    Node: 14.17.3 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.13 - /usr/local/bin/npm
  npmPackages:
    jest: 27.0.3 => 27.0.3 
@strunkandwhite
Copy link

I was running into this when I had both @jest/[email protected] and @jest/[email protected] in my yarn.lock. Once I updated the dependency that required @jest/[email protected], and yarn why @jest/fake-timers only yielded => Found "@jest/[email protected]", I stopped having this issue.

@FrozenKiwi
Copy link

FrozenKiwi commented Aug 1, 2021

Is there any reason the test can't just look for the existence of setSystemTime?

        if (fakeTimers instanceof _fakeTimers().ModernFakeTimers) {

becomes

        if (fakeTimers.setSystemTime) {
          fakeTimers.setSystemTime(now);
        } else {

The current check seems oddly fragile - Duck-typing seems safe enough. I haven't dug through the code all that much, but if we -need- the packages de-duped (eg, singleton access or something) then perhaps we could tweak the error message to be a bit more explicit?

@cmavelis
Copy link

I was running into this when I had both @jest/[email protected] and @jest/[email protected] in my yarn.lock. Once I updated the dependency that required @jest/[email protected], and yarn why @jest/fake-timers only yielded => Found "@jest/[email protected]", I stopped having this issue.

My yarn why only yields => Found "@jest/[email protected]", but I have the issue. Already was in that state to begin with though, so maybe that means something?

minijus added a commit to minijus/jest that referenced this issue Oct 10, 2021
minijus added a commit to minijus/jest that referenced this issue Oct 10, 2021
minijus added a commit to minijus/jest that referenced this issue Oct 15, 2021
@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 Nov 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants