-
-
Notifications
You must be signed in to change notification settings - Fork 771
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
Add isSealed check to is-es-module. #1803
Conversation
Thank you, @jdalton! That seems like a very reasonable addition in these times of change towards ESM. Would you mind adding a minimal test to show its utility? I think you should find what you need in the |
Thanks @fatso83. Will do! Update: Test added. |
It looks fine and all, but I was wondering if you could try and explain to me (slowly 🐢) the actual utility of adding this (meaning: an actual scenario where this would be used)? After seeing the test, I was a bit uncertain of what I was actually looking at, as the form of the module being tested seemed somewhat contrived. I am assuming that the reason this PR comes up is that you came across some actual use case that the current check prevented, so I am just curious to what this is fixing/enabling :) Normally, the only objects that "have the toStringTag of Module" are ES Modules. The only reason another object that is not an ES Module would fulfill this is by posing as an ES Module. So mocking something that is already posing as something else seems a bit contrived, hence my curiosity. |
Sure thing. In my case I write With the new import sinon from 'sinon'
import assert from 'assert'
import * as obj from './index'
assert.equal(obj.foo(), 1)
const spy = sinon.spy(obj, 'foo')
obj.foo(42)
obj.foo(1)
console.log(obj.foo.isSinonProxy) // true
console.log(spy.withArgs(42).calledOnce) // true
console.log(spy.withArgs(1).calledOnce) // true |
Perfect! That makes total sense, as it revolves around tooling, and not "your mama's development" :-) Thanks for the details. |
5.0.8 out |
@jdalton thank you! If I understand this correctly, this solves the problem of stubbing things on modules. If that's the case, then we should write something about this for the how to section, so we can point to that for when people show up with questions about modules. |
This doesn't solve stubbing on built-in module namespace objects. The |
@jdalton that was what I meant to say, when using |
Yep! Check it out 🎉 |
This PR adds an
Object.isSealed
check to theisESModule
helper. This allows objects that may have thetoStringTag
ofModule
to be mocked as long as they aren't sealed (ES namespace objects are sealed).