Skip to content
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

TypeError: Cannot read property 'binaryOptions' of undefined #142

Closed
andresmgot opened this issue Mar 17, 2020 · 2 comments
Closed

TypeError: Cannot read property 'binaryOptions' of undefined #142

andresmgot opened this issue Mar 17, 2020 · 2 comments

Comments

@andresmgot
Copy link

andresmgot commented Mar 17, 2020

Hello! I have just upgraded yaml from 1.7.2. to 1.8.2 and found the following problem:

Screenshot from 2020-03-17 12-21-12

I guess it's an issue related to how things are exported now. Something I need to change in order to upgrade?
Note that I am using Typescript

@eemeli eemeli closed this as completed in 6c254a5 Mar 19, 2020
@eemeli
Copy link
Owner

eemeli commented Mar 19, 2020

The immediate cause of this issue is that your Webpack config should not be mapping yaml/types to yaml/types.mjs but to yaml/browser/types.js. The change in 1.8.0 that's causing this is that the Node ES module endpoint types.mjs was added, and Webpack prefers .mjs over .js where available. Hence it's matching to the file in the root, rather than under browser/, because the "browser" field in the yaml package.json only includes a "./types.js" mapping.

I added browser mappings for ./types.mjs and ./util.mjs, which should fix this. Tested it manually with Webpack, and checked the Rollup code to make sure it'll behave the same way (provided that Rollup is configured to read browser fields).

The fundamental issue here is that when importing a CJS module from an ESM context in Node 13, its __esModule field is ignored. Webpack, on the other hand, parses it fine, and presents it as an ES module with is default & named exports. And for Node, the ESM and CJS endpoints need to internally resolve to the same sources in order to avoid a dual package hazard.

@andresmgot
Copy link
Author

Great, thanks for the detailed response! Indeed importing yaml/browser/types fixes the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants