Unable to load @react-aria/textfield as ESM module

[jwnx]

🐛 Bug Report

Starting with version 3.5.1, the contents of @react-aria/textfield/dist/module.js seems to have become garbled. The file at version 3.5.0 looks good and can be correctly loaded as an ESM module.

🤔 Expected Behavior

The file to be loaded correctly, for example, by jest.

😯 Current Behavior

The module is not understood by node:

SyntaxError: The requested module '@react-aria/textfield' does not provide an export named 'useTextField'

💁 Possible Solution

🔦 Context

Trying to run unit tests against a component that depends on @react-aria/textfield.

💻 Code Sample

🌍 Your Environment

Software	Version(s)
react-spectrum	3.5.2
Browser	Firefox
Operating System	macOS

🧢 Your Company/Team

🕷 Tracking Issue (optional)

[devongovett]

The last line does have the export defined... so not sure what would be happening.

export {$7811e7c771d6e497$export$712718f7aec83d5 as useTextField, $7f9aed3807b71324$export$4f384c9210e583c3 as useFormattedTextField};

[beamery-tomht]

Similar issue moving from @react-aria/utils": "3.11.0 to @react-aria/utils": "3.11.1 or 3.11.2. It worked fine before, change the version and import { useId } from '@react-aria/utils' doesn't work in ts-node/esm loader for mocha tests.

[beamery-tomht]

Had a quick skim over your history for react-aria/utils to see what changes might have introduced it - only thing that stands out is upgrading parcel

[devongovett]

Could someone provide reproduction steps for this?

[kherock]

Possibly related, I'm having issues using these components in NextJS SSR while native ESM is enabled due to a missing "type": "module" or .mjs file extension on the module files. NextJS is resolving the "module" path, but when Node tries to load it, it expects CJS without either of the criteria for ESM being fulfilled.

[kherock]

Ok I figured it out, this particular problem is an issue with the CJS export. Node.js does attempt to load ESM exported by this library unless explicitly asked to (e.g. import '@react-aria/textfield/dist/module.js').

compare these two and scroll to the bottom:
https://unpkg.com/@react-aria/textfield@3.5.0/dist/main.js
https://unpkg.com/@react-aria/textfield@3.5.1/dist/main.js

Node.js has a somewhat flaky heuristic for providing named exports for CJS: https://nodejs.org/api/esm.html#commonjs-namespaces

The important line is here

Live binding updates or new exports added to module.exports are not detected for these named exports.

Parcel 2 changed from assigning to exports to using binding function with parcel$exportWildcard.

To reproduce, just run a script ending in .mjs in Node.js, with contents like

import { mergeProps } from '@react-aria/utils'; // v3.12.0

Then downgrade utils to 3.11.0 and watch the error go away

[beamery-tomht]

Bump. Any news on this?

[kherock]

@devongovett any way I can help on this? I'm blocked from updating any dependencies until this is resolved.

I see two options:

1. find a way to have Parcel revert back to assigning to exports normally, removing the parcel$exportWildcard helper
2. expose an exports map with a proper ESM export that Node can use

I'm not sure if I have the bandwidth to look at option 2. since I think it would involve proposing an implementing a solution to parcel-bundler/parcel#4155. I could probably could come up with a workaround using the release scripts in the meantime.

[devongovett]

What is causing a CJS module to be loaded as ESM in the first place?

[kherock]

CJS isn't loading as ESM, Node is just statically analyzing it for named exports. This analysis happens when you request a module like the following from an ESM context (e.g. a file ending in .mjs)

import { mergeProps } from '@react-aria/utils';

And the reason Node is even looking at the CJS file in the first place is because its ESM loader will only look for it at .exports.import or .exports.default¹

Footnotes

1. Additionally, the entry at .exports.import needs to end in .mjs, or the whole package otherwise will need "type": "module". Without this, Node will attempt parsing the file as CJS and throw at the first instance of import ↩

[devongovett]

I got that, but where is this ESM import of a React Aria package running in node? You mentioned Next.js but I thought they used CJS.