feat(jest-environment-{node,jsdom}): allow specifying customExportConditions

[jeysal]

Allow customExportConditions in both of our environments.
Tested using e2e.
Documented in an awkward but the only place.

[SimenB]

Mention here? https://jestjs.io/docs/configuration#testenvironmentoptions-object

Only suggestion

[SimenB]

Add support to node env as well?

[jeysal]

Yeah that's the only place where it could make sense to mention, especially if we add support for node too. Slightly awkward though since they're environment-specific and thus all just "example" mentions

[jeysal]

@SimenB added a lil mention to docs, and made node env also support it

[SimenB]

Great stuff

[SimenB]

Oh, maybe tweak "override" wording https://jestjs.io/docs/upgrading-to-jest28#packagejson-exports

[SimenB]

https://github.com/facebook/jest/releases/tag/v28.1.0

[josundt]

@SimenB It would be nice if the initial value of JSDomEnvironment.customExportConditions in jest-jsdom-environment was changed from ['browser'] to ['jsdom', 'browser'].

Rationale:
node, browser and jsdom are three different runtime environments with different properties (where jsdom really is a full node environment with an partly emulated browser environment on top).

In the jsdom runtime context, most of the time you want a package's "browser" conditional export, but other times it is better to use the "node" conditional export, since jsdom is missing certain browser features like crypto or fetch.

It would be nice if cross-env package authors were able to add a conditional "jsdom" export to package.json to direct to the correct implementation when running the code in a jsdom runtime context, f.ex. when running Jest.

We actually already added "jsdom" conditional exports in addition to "node" and "browser" for our internal packages to make them work with Jest unit tests, and for now we set jest.config's testEnvironmentOptions.customExportConditions to ['jsdom', 'browser'].

But I believe this could have been the initial value for JSDomEnvironment.customExportConditions.
It would be a non-breaking change that would simplify making cross-env packages work in node, browsers and tests.

[SimenB]

I don't think we'll add any defaults beyond ones specified here: https://nodejs.org/api/packages.html#community-conditions-definitions

[josundt]

@SimenB I can live with that, I can anyway configure it manually in jest.config.js.

But personally I still think it would be correct to express this environment condition, since the runtime environment in my opinion is not correctly identified by "browser" or "node".

FYI: Webpack is utilizing non-standard custom conditions quite extensively to enable advanced features:
https://webpack.js.org/guides/package-exports/#conditions

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