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

[rschristian]

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 (nodejs/node#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]

You should report this to esm, we've never really supported it.

You should use native ESM (although the segfault (argh!) probably block that) or setup esm as a transformer (doesn't seem like that landed: standard-things/esm#706, so maybe use babel or typescript?).

---

That said, if you could bisect which change caused the regression, we might be able to get a fix in as long as it's not too ugly 🙂

[rschristian]

Alright, thanks! I do appreciate there's likely a ton of surface area there for a pretty uncommon use case.

I certainly will take a look at bisecting, see if I can track down the exact change.

Definitely might be time to look for an alternative, as esm looks to be unmaintained for the past few years as well.

Do you prefer I close this as it might be an upstream issue? Assuming I can come back in say a week and update regardless depending on what I find.

[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! 😀

[rschristian]

I spent a few hours trying to bisect the issue tonight, without a ton of success.

As far as I can tell, the commit that caused the issue was the 25.1.0 release itself. That being said, the only way I could actually reproduce this was by using yalc, which I've found to be incredibly finicky and inconsistent. Using the instructions listed in the contributing doc here, the error does not show up on the known-bad v25 release, so I don't really know what's going on there.

I suppose my only guess is that it's not jest itself, but one of the myriad of other libraries that gets shipped with it? No idea how to start tracking that down.

I also ran into all sorts of issues with node-gyp and a broken Babel release or two, so it's perfectly possible I screwed something up when trying to resolve those.

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

[rschristian]

Interesting. Gave that a shot, but still, on the v25.1.0 release (5dcc480), it seems to correctly run. Head of main does fail, though that's not exactly useful as 25.1.0 should be failing too.

I don't think I can spend more time trying to track this down, sorry. Seems like a non-stop fight against the tooling more than anything; none of it first-party, for what it's worth, but Yarn (2+) tripping over itself and losing files, gyp, and then Babel shenanigans.

Shall I close out this issue? I think we're probably pretty happy downgrading to v24.9.0 until that import() segfault issue is finally corrected upstream. I don't want to waste anyone else's time looking into this rather niche issue. I think we're the only one's who've hit it, after all 😅

[SimenB]

Fine by me 🙂 Note that if you install [email protected] you'll still get ^ range for everything else, so you're getting latest v25 in practice and might not be testing actual 25.1.0?

[rschristian]

Ah, fair point. Might've been it, though tracking down the actual issue I imagine would still be difficult.

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