feat: support exports in package.json

[SimenB]

Summary

Add support for exports in package.json.

This is missing a bunch of tests. Also, we need to add node condition, and then use shouldLoadAsEsm on the returned value in the runtime.

I also think we need to ensure conditions is always passed. So some stuff in normalize have to move (specifically the stuff that is loaded in the user's env like setuFiles etc - that needs to be provided the correct conditions)

Fixes: #9771

Test plan

Will be interesting to see how CI likes this.

Some basic tests added, will add way more involved ones before merging

[SimenB]

I had to create this and the one below otherwise resolve finds the package.json of jest-runtime itself (which has exports, thus it fails)... Not sure how to deal with this - is it ok? If so, it's at least a breaking change

[codecov-commenter]

Codecov Report

Merging #11961 (c7ed620) into main (df0c496) will increase coverage by 0.01%.
The diff coverage is 91.30%.

@@            Coverage Diff             @@
##             main   #11961      +/-   ##
==========================================
+ Coverage   68.46%   68.47%   +0.01%     
==========================================
  Files         324      324              
  Lines       16961    16968       +7     
  Branches     5055     5060       +5     
==========================================
+ Hits        11612    11619       +7     
  Misses       5317     5317              
  Partials       32       32              

Impacted Files	Coverage Δ
packages/jest-resolve/src/defaultResolver.ts	91.17% <90.90%> (+3.17%)	⬆️
packages/jest-runtime/src/index.ts	55.41% <100.00%> (-0.11%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update df0c496...c7ed620. Read the comment docs.

[SimenB]

Since I've had to add a few package.json here and there, I'm afraid this is a breaking change so will have to wait for Jest 28 (even if I do think the semantics are more correct).

Alternative is to add it behind a flag, but... meh

[SimenB]

OK, I think this is good to go now. Just need to add some more tests, but from manual testing this seems to work

[antongolub]

@SimenB, I have a lemming question: if we load some cjs package, which requires another package with dual export ({"type": "module", "main": "...", "exports": {...}), what will be the entry point for the latter?

[piranna]

@SimenB, I have a lemming question: if we load some cjs package, which requires another package with dual export ({"type": "module", "main": "...", "exports": {...}), what will be the entry point for the latter?

In latests versions of Node.js, if there's an exports entry, main one is ignored.

[antongolub]

Аha. It should be. But we have a custom resolver here)

[SimenB]

Yep, same here. If exports, main is ignored. If the require/import comes from your own code or in node_modules doesn't matter

[SimenB]

I'll publish a beta release after landing this (probably tomorrow), at which point people testing it would be great 🙂 There are probably still bugs here

[github-actions]

This pull request 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.