You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello. I am refactoring an existing codebase that uses a testing utility called sinon.useFakeTimers(). Calling this method basically replaces functions like setTimeout and clearTimeout in the global scope. I don't like this, but it's unfeasible to change this at this point.
The problem is: to work around another unrelated issue, I want to wrap some of these tests using p-timeout. Since p-timeout (obviously) uses setTimeout and clearTimeout from the global scope, which got replaced by sinon.useFakeTimers(), nothing times out correctly anymore. I would like to be able to make p-timeout keep using the original versions of setTimeout and clearTimeout.
Some ideas I had:
Option 1: A new customTimers option could be added to allow the caller to specify custom setTimeout and clearTimeout implementations (and in my case, I would provide the original implementations to it). I would use it like this:
Option 2: A new preventTimerStubbing option that, if true, would use the implementations of setTimeout and clearTimeout that were cached when the module was loaded (instead of reading the global scope directly), making it immune to future replacements of the global implementations. This has the downside that if require('p-timeout') is called too late, the replacements will already have taken place anyway. This wouldn't be a problem for my specific case though.
Option 3: Just add const { setTimeout, clearTimeout } = global to the source code directly, making p-timeout immune to this type of mocking (unless the module is required too late, in which case there wouldn't be any difference). The downside is that it might break lots of people's codes, if they are also using sinon.useFakeTimers() and their code (or even any transitive dependency) uses p-timeout internally.
Would you be willing to accept any of these? If yes, which one? Let me know and I will open a PR. I prefer option 1, but it's your call.
Othewise, I understand - I might then just create and use a fork, or patch it with pirates.
Thank you!
The text was updated successfully, but these errors were encountered:
Hello. I am refactoring an existing codebase that uses a testing utility called
sinon.useFakeTimers()
. Calling this method basically replaces functions likesetTimeout
andclearTimeout
in the global scope. I don't like this, but it's unfeasible to change this at this point.The problem is: to work around another unrelated issue, I want to wrap some of these tests using
p-timeout
. Sincep-timeout
(obviously) usessetTimeout
andclearTimeout
from the global scope, which got replaced bysinon.useFakeTimers()
, nothing times out correctly anymore. I would like to be able to makep-timeout
keep using the original versions ofsetTimeout
andclearTimeout
.Some ideas I had:
customTimers
option could be added to allow the caller to specify customsetTimeout
andclearTimeout
implementations (and in my case, I would provide the original implementations to it). I would use it like this:preventTimerStubbing
option that, if true, would use the implementations ofsetTimeout
andclearTimeout
that were cached when the module was loaded (instead of reading the global scope directly), making it immune to future replacements of the global implementations. This has the downside that ifrequire('p-timeout')
is called too late, the replacements will already have taken place anyway. This wouldn't be a problem for my specific case though.const { setTimeout, clearTimeout } = global
to the source code directly, makingp-timeout
immune to this type of mocking (unless the module is required too late, in which case there wouldn't be any difference). The downside is that it might break lots of people's codes, if they are also usingsinon.useFakeTimers()
and their code (or even any transitive dependency) usesp-timeout
internally.Would you be willing to accept any of these? If yes, which one? Let me know and I will open a PR. I prefer option 1, but it's your call.
Othewise, I understand - I might then just create and use a fork, or patch it with
pirates
.Thank you!
The text was updated successfully, but these errors were encountered: