-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resolver.unstable_enablePackageExports results in exception around interopRequireDefault #984
Comments
that's because that option doesn't exists? AFAIK there's only |
Correct 👍 closing this one |
this was actually a typo when writing the issue, the flag I am seeing this error with is Updated the issue, please reopen |
@deodad can you provide the full metro config file for the repro? I would like to make sure it's not a misconfiguration |
sure thing
|
@kelset I'll take a look at this tomorrow. Just to check, is that repro on a fresh |
I'm unable to take a close look at the moment, but I suspect this has something to do with e70ceef. My guess is that Babel generates code that assumes the |
If my suspicion above is correct: One approach could be to make the resolver assert either the In practice we would end up using the |
The problem we'd have here is that effectively in OSS takes us back to facebook/react-native#36584, which was reverted because it breaks compatibility with ESM-only packages. We've come back a few times to the idea that we should assert |
yes |
Is the issue that there are some previously working NPM packages which declare a If that is the issue, one more fallback strategy might be using
|
@NickGerleman - Yeah, we could remove the Indeed if we've reached the source file by successfully following the Re the particular issue with One possibility might simply to downgrade it - the problem export was only introduced in |
Another option, though a gnarly one that's probably breaking in some way - set the |
Summary: This is a workaround for facebook#984. It adds a specific exception in the resolver for `babel/runtime` to prevent asserting the `"import"` condition name on these modules (when using Package Exports). This is necessary so that the CJS version of these Babel helpers are resolved, which enable CJS/MJS interop for all other modules (given our current strategy of resolving both `"require"` and `"import"` in all other packages and using Babel-driven ESM compatibility). This workaround is removable if/when any of: - babel/babel#15643 is merged and updated in React Native. - We implement dynamic handling of `"require"` and `"import"` conditions via ESM support in a future version of Metro. Changelog: **[Experimental]** Fix `babel/runtime` issue when using Package Exports Differential Revision: D46107056 fbshipit-source-id: 6bf32ccf412cb57a1705a6ae3ee6d8c35cb306d5
Summary: Pull Request resolved: facebook#990 This is a workaround for facebook#984. It adds a specific exception in the resolver for `babel/runtime` to prevent asserting the `"import"` condition name on these modules (when using Package Exports). This is necessary so that the CJS version of these Babel helpers are resolved, which enable CJS/MJS interop for all other modules (given our current strategy of resolving both `"require"` and `"import"` in all other packages and using Babel-driven ESM compatibility). This workaround is removable if/when any of: - babel/babel#15643 is merged and updated in React Native. - We implement dynamic handling of `"require"` and `"import"` conditions via ESM support in a future version of Metro. Changelog: **[Experimental]** Fix `babel/runtime` issue when using Package Exports Differential Revision: D46107056 fbshipit-source-id: e3b8f453d98a45c7b10df1e6c2ff97b4f017529f
Summary: Pull Request resolved: facebook#990 This is a workaround for facebook#984. It adds a specific exception in the resolver for `babel/runtime` to prevent asserting the `"import"` condition name on these modules (when using Package Exports). This is necessary so that the CJS version of these Babel helpers are resolved, which enable CJS/MJS interop for all other modules (given our current strategy of resolving both `"require"` and `"import"` in all other packages and using Babel-driven ESM compatibility). This workaround is removable if/when any of: - babel/babel#15643 is merged and updated in React Native. - We implement dynamic handling of `"require"` and `"import"` conditions via ESM support in a future version of Metro. Changelog: **[Experimental]** Fix `babel/runtime` issue when using Package Exports Reviewed By: motiz88 Differential Revision: D46107056 fbshipit-source-id: 5c34c5b3e1aaec16b998499401c81fadee34c30d
Summary: Pull Request resolved: #990 This is a workaround for #984. It adds a specific exception in the resolver for `babel/runtime` to prevent asserting the `"import"` condition name on these modules (when using Package Exports). This is necessary so that the CJS version of these Babel helpers are resolved, which enable CJS/MJS interop for all other modules (given our current strategy of resolving both `"require"` and `"import"` in all other packages and using Babel-driven ESM compatibility). This workaround is removable if/when any of: - babel/babel#15643 is merged and updated in React Native. - We implement dynamic handling of `"require"` and `"import"` conditions via ESM support in a future version of Metro. Changelog: **[Experimental]** Fix `babel/runtime` issue when using Package Exports Reviewed By: motiz88 Differential Revision: D46107056 fbshipit-source-id: 06c18de031458d6016ec7cf4101518e8bc1a174a
Resolved in https://github.com/facebook/metro, shipping today in Metro 0.76.5 and will also be updated in React Native CLI today. |
New Version
0.72.RC-3
Old Version
na
Build Target(s)
io sim
Output of
react-native info
Issue and Reproduction Steps
npx react-native@latest init RN0720RC3 --version 0.72.0-rc.3
set resolver.unstable_enablePackageExports true in metro.config.js
yarn start
The text was updated successfully, but these errors were encountered: