Switch all ESM dist to .mjs

[aduh95]

Jest 28 supports "exports" field in package.json, and will interpret ./dist/preact.module.js as CJS because it's using .js extension and the package.json doesn't contain "type": "module".
Switching to .mjs extension would fix the issue.

[JoviDeCroock]

we already have .mjs here, correct me if I'm wrong but apart from chromium browsers don't support the .mjs extension yet, so from what I can tell Jest should be using exports.import rather than exports.browser

[aduh95]

Browsers don’t care about the extension, they all support .mjs on that regard.

Jest should be using exports.import rather than exports.browser

Jest is using exports.browser when using the jest-environment-jsdom environment, you may or may not agree with that but that’s how they’re doing it 😅 anyway, Preact should be using .mjs, or add "type": "module" and use .cjs extension for CJS file, otherwise it’s hurting their users that use tooling that follow the same logic as Node.js.

[JoviDeCroock]

it’s hurting their users that use tooling that follow the same logic as Node.js.

It's not, Node uses this correctly as it imports from import and not from browser if Jest want to import from the browser tag it feels more appropriate to start disregarding the type: module stuff and rely on the browser semantics rather than the node ones 😅

[aduh95]

Any reason not to use .mjs though?

[JoviDeCroock]

The thing is we could change the export map to use .mjs but we would have to leave the .module.js file intact as people could be relying on that directly (unsafe though but let's try not to break people's stuff :p). Doing some quick checks and unpkg/skypack do leverage the correct mime when serving from their CDN. As we are not touching the UMD file we can be quite sure we don't have to check if people fill in the correct mime there 😅 CC @developit @marvinhagemeister are you seeing any issues here that I am overlooking?

[developit]

I believe the reason we didn't go with .mjs was because it forced webpack into strict module mode which was causing duplicate copies of Preact for codebases with mixed import+require. I believe that problem is now solved via the module export field, so we could move exclusively to using .mjs.

[rschristian]

This isn't safe to change outside of a semver major. A lot of tools/versions of tools can consume "module" but don't all support .[cm]js extensions.

A few months ago immer stumbled into an issue making this change, discovering that Metro didn't support .mjs. Only as of last month has that been rectified.

While I doubt Metro would be an issue for us, that just goes to show that support is not as widespread as we may hope. Node isn't going to consume "module" so it shouldn't need to adhere to Node's file extension semantics.

[InfiniteXyy]

I found a workaround here to use jest 28+, with preact,
You can use customExportConditions option to force jest not to resolve the "browser" field.

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

{
  "testEnvironmentOptions": {
    "customExportConditions": [
      "node",
      "node-addons"
    ]
  }
}

[arturi]

Just faced this again when trying to use preact/hooks in a new module in uppy.io, we had to patch Preact in uppy again: transloadit/uppy@11f1476.

[rschristian]

I found a workaround here to use jest 28+, with preact, You can use customExportConditions option to force jest not to resolve the "browser" field.

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

{
  "testEnvironmentOptions": {
    "customExportConditions": [
      "node",
      "node-addons"
    ]
  }
}

FWIW we did land this in the jest preset, but it has a rather big issue

[rschristian]

Going to close this out as it's not safe for us to touch in v10 and has been addressed in (what exists of) v11