[Bug]: v30 beta.8 ignores `testEnvironmentOptions.customExportConditions`

[anomiex]

Version

30.0.0-beta.8

Steps to reproduce

1. Unzip this example repository: test.zip
2. Run pnpm install
3. Run pnpm --filter=a test (or cd a then pnpm test).

You can change the jest dependency version to ^29 or 30.0.0-beta.5 to see it pass.

Expected behavior

 PASS  tests/foo.test.js
  ✓ Test (2 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.145 s, estimated 1 s
Ran all test suites.

Actual behavior

 FAIL  tests/foo.test.js
  ✕ Test (3 ms)

  ● Test

    expect(received).toBe(expected) // Object.is equality

    Expected: "src"
    Received: "built"

      2 |
      3 | test( 'Test', () => {
    > 4 |     expect( foo() ).toBe( 'src' );
        |                     ^
      5 | } );
      6 |

      at Object.toBe (tests/foo.test.js:4:21)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        0.2 s, estimated 1 s
Ran all test suites.
 ELIFECYCLE  Test failed. See above for more details.

Additional context

Probably #15619 missed passing the customExportConditions through to the new resolver.

Environment

System:
    OS: Linux 6.12 Debian GNU/Linux 13 (trixie) 13 (trixie)
    CPU: (16) x64 AMD Ryzen 7 7840U w/ Radeon  780M Graphics
  Binaries:
    Node: 22.16.0 - /usr/bin/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 10.9.2 - /usr/bin/npm
    pnpm: 10.11.1 - /usr/local/bin/pnpm
  npmPackages:
    jest: 30.0.0-beta.8 => 30.0.0-beta.8

[anomiex]

Probably #15619 missed passing the customExportConditions through to the new resolver.

After some further investigation, it looks like I guessed wrong on that. It seems that the conditions do get passed to unrs-resolver, but unrs-resolver doesn't handle them correctly. Looks like #15619 (comment) even changed a test that would have caught this bug.

https://nodejs.org/api/packages.html#conditional-exports specifies

Within the "exports" object, key order is significant. During condition matching, earlier entries have higher priority and take precedence over later entries. The general rule is that conditions should be from most specific to least specific in object order.

In other words, it's the order of the keys in package.json that's supposed to determine it, not the order of the resolver's list of conditions.

[JounQin]

In other words, it's the order of the keys in package.json that's supposed to determine it, not the order of the resolver's list of conditions.

#15619 (comment)

As I mentioned, node -C x -C require -C import vs node -C x -C import -C require work different.

cc @cpojer What's your opinion here?

[cpojer]

So the problem is that @anomiex's test is using the wrong order for exports or is unrs doing the wrong thing?

[JounQin]

So the problem is that @anomiex's test is using the wrong order for exports or is unrs doing the wrong thing?

Yes. On unrs-resolver's side, the related PR is unrs/unrs-resolver#115.

I'll raise an issue to node first to discuss the order of -C via cli.

[cpojer]

Alright, so Jest is correct and we don't need to make any changes, and @anomiex got caught out by the behavior change between Jest 29 and 30?

[JounQin]

It seems I cannot reproduce it anymore: JounQin/test#4

I'll change the behavior per spec again... Sorry for this.

---

Done. #15654

cc @cpojer

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