-
Notifications
You must be signed in to change notification settings - Fork 108
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
support util.promisify in Node #292
Conversation
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.
Wooo!
Should do setImmediate
at the same time: https://nodejs.org/api/timers.html#timers_setimmediate_callback_args
src/lolex-src.js
Outdated
@@ -21,6 +21,7 @@ function withGlobal(_global) { | |||
hrtimePresent && typeof _global.process.hrtime.bigint === "function"; | |||
var nextTickPresent = | |||
_global.process && typeof _global.process.nextTick === "function"; | |||
var utilPromisify = _global.process && require("util").promisify; |
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.
_global.process
as a "I am in node" check?
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.
Just be sure we are targetting the right global
here ... Should not this strictly be globalObject
(as that's where the promisify function will be required from in the runtime)? It's not certain that people will pass a custom global with all of the props of the runtime.
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.
_global.process
as a "I am in node" check?
Yeah this seems to be one of the popular ways
https://stackoverflow.com/questions/4224606/how-to-check-whether-a-script-is-running-under-node-js
Just be sure we are targetting the right
global
here ... Should not this strictly beglobalObject
(as that's where the promisify function will be required from in the runtime)? It's not certain that people will pass a custom global with all of the props of the runtime.
TBH I don't think I have the necessary knowledge of what the use cases for non-defaultImplementation
s / the withGlobal
function are to judge whether there will be cases where the provided _global
looks like a Node environment, but our actual global scope does not have require
. However FWIW I think it would be unintuitive to have vastly different conditions for applying e.g. the nextTick
and util.promisify
special handling, so that's why I'd prefer this.
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.
withGlobal
was added for jest support so we can pass in the jsdom global instead of the global env of the test runner.
Should probably be considered a bug that we inject process
in that case, but removing it would break all of the process.env.NODE_ENV
checks people have, but that's not really relevant here
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.
So then it'll apply to the jest-environment-jsdom
case anyway because it has process
.
Imagining that I pass in e.g. a DOM global that does not have Node things like process
, I would probably want it to not apply the promisify change (even though it could, using the outside require
), just like it doesn't apply the nextTick
change, I think?
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.
I think inspecting _global
is correct - if the global used to instantiate lolex
pretends to be from node (by having a process
property) we should assume we can require('util');
safely and go with that.
src/lolex-src.js
Outdated
@@ -21,6 +21,7 @@ function withGlobal(_global) { | |||
hrtimePresent && typeof _global.process.hrtime.bigint === "function"; | |||
var nextTickPresent = | |||
_global.process && typeof _global.process.nextTick === "function"; | |||
var utilPromisify = _global.process && require("util").promisify; |
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.
Just be sure we are targetting the right global
here ... Should not this strictly be globalObject
(as that's where the promisify function will be required from in the runtime)? It's not certain that people will pass a custom global with all of the props of the runtime.
ff09789
to
b370ab6
Compare
You haven't addressed "Should do
It has hit people in Jest, which is why we have tests for checking that we still work even if people swap out globals (e.g. the whole reason https://github.com/facebook/jest/blob/master/scripts/babel-plugin-jest-native-globals.js exists. That transform only guards Jest's own source code though, not other libraries). I'm fine with doing it separately, it's nothing to block on |
b370ab6
to
9e86833
Compare
Right, always miss the comments in the reviews themselves 😅 pushed 👍
I know, it was more of a "are the people changing globals going to be the same people using lolex fake timers" ;D |
(Build error also happens on master, |
@jeysal I can't see why this branch would fail to build on Circle. Would you mind rebasing it, to see if that might solve the build error in Circle? |
9e86833
to
705af40
Compare
done |
Codecov Report
@@ Coverage Diff @@
## master #292 +/- ##
==========================================
+ Coverage 92.61% 92.74% +0.12%
==========================================
Files 1 1
Lines 542 551 +9
==========================================
+ Hits 502 511 +9
Misses 40 40
Continue to review full report at Codecov.
|
worked 🎉 |
@fatso83 are you happy with the changes made? Is there anything left to do? |
(I've put @SimenB's suggestion about capturing |
wow, wow, wow, I didn't know I was the party pooper here. Sorry for not seeing this! For the next time, there is absolutely no need to wait for my approval on anything, especially if I don't respond (which might happen when I do "Mark all as read" if the number of dependencybot PRs get too high). You guys are collectively way more knowledgeable about this than me, so merge ahead the next time you see things being addressed 😸 |
|
By the way this doesn't work for I assume that's because this for loop is intent on copying the properties on However, the I monkey patched my test with. const clock = sinon.useFakeTimers();
setTimeout[util.promisify.custom] = clock.setTimeout[util.promisify.custom]; |
The for...in loop would copy only string own-properties to installed methods, which would omit util.promisify.custom necessary for util.promisify support on Node as added in sinonjs#292. Instead, copy all own-property descriptors to get both Symbol own-properties and to copy any getters/setters that may be added in the future. Add tests for util.promisify behavior. Fixes: sinonjs#347 Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Purpose (TL;DR) - mandatory
Fixes #223, similar to what we did for
jest-fake-timers
.Noticed after starting there's already #227, but that seems stale and I'm not sure what some of the changes are for.
I'll do what I can to incorporate any review comments and get this through! 😅
If there's consensus that storing a
global.Promise
backup is a good idea, can do that, but would do another PR first, changing this in existing code.