[Bug]: jest fails when @cspot/source-map-support and yarn 2+ pnp are involved.

[francisu]

Version

27.5.1

Steps to reproduce

Use this repo: https://github.com/noahnu/repro-source-map-error (h/t @noahnu for making this)

1. yarn install
2. yarn ts-node --transpile-only $(yarn bin jest)

Expected behavior

Test should pass.

Actual behavior

 % yarn ts-node --transpile-only $(yarn bin jest)
 FAIL  ./index.test.ts
  ● Test suite failed to run

    Cannot find module 'source-map-support' from '/Users/francis/temp/repro-source-map-error/.yarn/cache/@cspotcode-source-map-support-npm-0.7.0-456c3ea2ce-9faddda775.zip/node_modules/@cspotcode/source-map-support'

      at resolveSync (.yarn/cache/resolve-patch-bad885c6ea-c79ecaea36.zip/node_modules/resolve/lib/sync.js:111:15)

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        0.132 s
Ran all test suites.

Additional context

The original issue is: cspotcode/node-source-map-support#35, but it seems to be a Jest problem.

Here is the a patch that fixes it (thanks to @cspotcode )

Replace this code:

https://github.com/facebook/jest/blob/3a85065fe5604655e1337ffc1631f9999722c821/packages/jest-runner/src/runTest.ts#L213-L219

with:

  const resolved = require.resolve('source-map-support');
  runtime.requireInternalModule(resolved, resolved).install(sourcemapOptions);

This might be related to:

#8930
#11453

Environment

System:
    OS: macOS 12.1
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  Binaries:
    Node: 14.17.3 - ~/.nvm/versions/node/v14.17.3/bin/node
    Yarn: 3.1.1 - /usr/local/bin/yarn
    npm: 8.1.0 - ~/.nvm/versions/node/v14.17.3/bin/npm

[cspotcode]

Hi, replying to say that I'm following along and will be happy to answer any questions. Feel free to mention me directly.

[cspotcode]

Adding a bit more context:

In the highlighted snippet of jest code above:

runtime.requireInternalModule(require.resolve('source-map-support'), 'source-map-support')

...it appears to be emulating what would happen if "source-map-support" were, internally, to require itself. That is, a file within source-map-support attempted to do require('source-map-support'). I'm curious what necessitates this bit of code. I understand jest hooks into module resolution to support various testing features. However, in this case, jest is loading an internal dependency, so it seems unnecessary to obey any resolver hooks. Why is require('source-map-support') insufficient?

"@cspotcode/source-map-support" redirects require() of "source-map-support" to "@cspotcode/source-map-support" (cspotcode/node-source-map-support#23), as a drop-in replacement with additional bugfixes and features. (cspotcode/node-source-map-support#24) This is necessary because "@cspotcode/source-map-support" correctly handles multiple copies of the library, which avoids broken stack traces, but "source-map-support" does not. (cspotcode/node-source-map-support#28, evanw/node-source-map-support#209)

Given the above, I'm wondering what is the best path forward. Think my proposed patch solves the problem, but I don't understand why jest's current logic is necessary.

[SimenB]

However, in this case, jest is loading an internal dependency, so it seems unnecessary to obey any resolver hooks. Why is require('source-map-support') insufficient?

internal in this case means "load inside the vm sandbox, but since internal, skip all user config for resolution and transformation". The code linked here runs outside the sandbox

[cspotcode]

I halfway understand what you're saying. As a more concrete follow-up question to hopefully aid my understanding:

Is my proposed fix acceptable? If it's not, what rules is it breaking?

[SimenB]

Yeah, your fix seems correct, we should just delete line 217. Not sure why it was ever added...

[SimenB]

PR welcome :grin\

[francisu]

PR welcome :grin\

OK, I can do one tomorrow.

[SimenB]

ideally with some integration test that fails without the change. Possibly just the reproduction used in the OP

[francisu]

ideally with some integration test that fails without the change. Possibly just the reproduction used in the OP

Naturally

[cspotcode]

Awesome, thank you both!

[SimenB]

@francisu ping 🙂