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

[simon-paris]

🐛 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 jest@27.0.3 @jest/fake-timers@27.0.3
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]

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

[FrozenKiwi]

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]

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

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

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