[Bug]: Using `esm` package results in an empty object in Jest >= 25

Version

27.5.1

Steps to reproduce

1. Clone repo from https://github.com/rschristian/jest-esm-repro
2. yarn
3. node index.js -> output is { default: [ { foo: 'bar' } ] }
4. yarn jest ./index.test.js -> test fails, output is { default: {} }
5. Downgrade jest to 24.9.0 in package.json
6. yarn jest ./index.test.js -> test passes, output is { default: [ { foo: 'bar' } ] }

Expected behavior

The test should pass in newer Jest versions.

Actual behavior

The default export is always an empty object.

Additional context

Apologies for this being a bit old, but only just noticing it now. This works correctly in 24.9.0, but as of 25.0.0, it fails. Nothing in the change notes for 25 really stands out to me, and I imagine this should still function properly if it does work in Node itself without issue.

Over in preact-cli, we allow users to write their config files in ESM or CJS, resulting in this setup (use of the esm package). It seemingly is the only way to enable this behavior while also not breaking our test suite due to the upstream import() segfault bug (https://github.com/nodejs/node/issues/35889)

Environment

System:
  OS: Linux 5.16
  CPU: (4) x64 AMD Ryzen 7 5800X 8-Core Processor
Binaries:
  Node: 14.19.0 - /usr/bin/node
  Yarn: 1.22.17 - /usr/bin/yarn
  npm: 6.14.15 - /usr/bin/npm

[SimenB]

Yeah, I’d try to add a failing test to this repo (possibly in examples/ or something) and then bisect and run that. Linking properly sounds hard 😅 That said, yarn link should also work fine, but probably only into a separate minimal project rather than your own larger one. See e.g. https://github.com/facebook/jest/blob/3f3aa80254f2b2f365825c6ac5b5f0a2217631a5/scripts/verifyPnP.js#L71-L74 (note that you should use yarn v2 or v3 for the link, so yarn link --private --all ../jest or something if your project is a sibling)

[SimenB]

It is a regression even though we never explicitly supported esm. If the change on our side is trivial (or at least minimal, and also makes sense in isolation), I’m happy to land it. If it’s a hacky change we can close as downstream issue 🙂 Depends on the outcome of the bisect, I guess! 😀