Closed elicwhite closed 9 years ago
Is there any technical reason why proxyquireify couldn't handle the global setting?
I'm not sure, but won't have time to investigate/implement. However if you don't mind digging into the code, PRs are welcome.
If you need help just submit a PR that is in the works and we'll try to solve any problems you may run into.
While getting ready to look through the code and running the test suite locally, I get failures.
[test-peer-range] Installed browserify@
[test-peer-range] Passed: 5, 6, 7, 8, 9
[test-peer-range] Failed: 10, 11
Full log: http://pastebin.com/g0PW4nHZ
@TheSavior check https://github.com/thlorenz/proxyquireify/pull/39
I had to move the test for argument-validation to its own module to overcome the test failures. After that it passes the tests on all the browserify versions. Any progress on this issue? would be really nice to configure noCallThru
from the call to proxyquerify
.
Test failures should be resolved now. I don't believe Thorsten has the time to investigate whether this is possible and I definitely don't. I'd be more than happy to review a PR if either of you are up for working on this.
We use proxyquire and proxyquireify extensively in our test suites and have found that we consistently run into problems that are solved by adding
@noCallThru
to our proxyquireify calls.Is there any technical reason why proxyquireify couldn't handle the global setting?
It seems like all it would need to do is add the
'@noCallThru': true
key/value pair to the stub object if that setting is on.