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
getInteropBlock() to work with null prototype objects #3420
Conversation
I need to follow-up with a test specifically for the null prototype case. Current PR has just existing tests modified. Update: Added unit test to test this case specifically ✅ |
Codecov Report
@@ Coverage Diff @@
## master #3420 +/- ##
=========================================
Coverage ? 93.29%
=========================================
Files ? 172
Lines ? 6114
Branches ? 1823
=========================================
Hits ? 5704
Misses ? 218
Partials ? 192
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks!
Very welcome, and important to document why we do it this way, thanks a lot! |
Thank you @lukastaegert! |
…e objects
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Description
Currently, rollup attempts to detect how exports should be generated based on the exported values from the module entry.
named
), rollup returns an object with thenamed
property.named
), rollup returns an object with thedefault
and thenamed
property. It's important to note that if nooutput.exports
property is set, rollup warns in this case.On the other hand, when importing the default value from an external module, rollup injects some interop code extract the code right default value. This interop checks the presence of the
default
property on the exported object usingmodule.hasOwnProperty('default')
.I recently ran into a case where the interop code throws an error because
hasOwnProperty
is not defined on the external module. This happens because the module (module/a
) has a single default export and the default export value has no prototype. In this case, if another module (module/b
) imports the default export the interop code will throw becausehasOwnProperty
is not defined on the object.