fix: Fix user override of customExportConditions in custom env subclasses

[huntie]

Summary

Adjusts behaviour in jest-environment-jsdom and jest-environment-node (no breaking changes).

With customExportConditions exposed as a public property on each env class, and as previously tested in deno.test.mjs, subclasses can override "exports" conditions in two ways:

Previously, both overriding the property or reimplementing exportConditions() would mean that when a user attempted to override this in Jest config, this was ignored.

{
  testEnvironment: 'react-native/jest/react-native-env', // (via preset: 'react-native')
  testEnvironmentOptions: {
    customExportConditions: ['test', 'react-native'],
  },
}

These changes make sure this behaviour works for the property assignment case — and is covered by tests. We plan to make this load-bearing in the React Native Jest preset for 0.72.

Changes:

• Updates jest-environment-jsdom, jest-environment-node to use the customExportConditions property as a default, which will be overridden if set in config.projectConfig.testEnvironmentOptions.
• Renames deno.test.mjs/deno-env.js to custom-env (more generic).
• Adds custom-env-override-conditions.test.mjs with new test case (tests via @jest-environment-options doc comment).

Test plan

yarn jest e2e/__tests__/resolveConditions.test.ts

✅ Updated tests pass

[mrazauskas]

Would be useful to add configuration example you provided to the testEnvironmentOptions option documentation. Or is that clear? Hm.. Perhaps it is clear? (At first it sounded like this is new feature.)

[huntie]

@mrazauskas Believe this is present, but happy to improve.

Note: ⚠️ Incoming tweak to this PR, as I forgot the .test.js suffix on the new test and it wasn't being run!

[mrazauskas]

I took one more look and opened a PR to adding the examples. See #13991

[SimenB]

Note: ⚠️ Incoming tweak to this PR, as I forgot the .test.js suffix on the new test and it wasn't being run!

@huntie is it? 😀

[huntie]

So it turns out that neither of these patterns allows overriding via projectConfig.testEnvironmentOptions...

...because the property initialiser customExportConditions is assigned after the constructor runs (overwriting the parent class constructor) 😐.

1. ⬆️ For this reason, customExportConditions should perhaps be made private.
2. To get the same functionality, the extending class must merge the config object with any defaults and call the parent constructor (this provides an API free of the above footgun, without breaking changes, but is less intuitive and awkward in practice)
   • or, we update both NodeEnvironment and JSDOMEnvironment implementations to resolve the customExportConditions value in the accessor method instead. ⬅️ This approach is incoming.

[huntie]

PR is updated and now makes a small functional fix along with test updates (see previous comment), preferring a non-breaking approach.

@mrazauskas @SimenB Ready for review.

[huntie]

67be705:

• Add custom-env-conditions-method-override.js and related test, covering original test case of overridden exportConditions() method.

Ready for review.

[SimenB]

👍

[SimenB]

@huntie is this something you need released?

[huntie]

@SimenB Would be nice, but it's not super urgent — especially as Package Exports is shipping experimentally at first. Not a direct dependency for the config updates in React Native, just the edge case will get fixed under the next version :).

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

[SimenB]

https://github.com/jestjs/jest/releases/tag/v29.6.0