-
Notifications
You must be signed in to change notification settings - Fork 128
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
Should not try to attach to modules that export primitives #83
Conversation
This PR makes all of my tests pass for |
a23e60e
to
562f8a6
Compare
@jhnns I rebased this from master. What are your thoughts on this? I'd like to be able to make these modules share more and have a consistent API. |
@jhnns Bump. |
Does this mean that |
Btw: Thx for your PR 👍. I'll merge it asap. |
|
6f5252f
to
b752ffb
Compare
Good catch. Added a test case for null. |
Should not try to attach to modules that export primitives
Shipped with |
When people use rewire, they wouldn't typically try to explicitly rewire modules that export primitives.
However, since reweireify, rewire-global, and babel-plugin-rewire all get injected to every module, this needs to not blow up on objects that can't be attached to.
rewireify and rewire-global use
Object.isExtensible
instead of the type check. The behavior ofObject.isExtensible
change from es5 to es6. In ES5, it would throw if given something that was not an object. in ES6, it returns false. rewireify and rewire-global all run in the browser and all modern browsers have the es6 version of the functionality. Node 0.12 has the es5 functionality, so we need to use the type check instead.I added a test to make sure that it doesn't blow up on modules that return sealed objects.
Object.defineProperty
will run and not throw, but won't actually modify the object.