It might be useful for somebody to reuse our complicated-ass ESLint rules around use of global timers.
These rules, for example, disallow:
setTimeout();
global.setTimeout();
but they allow:
const setTimeout = global.setTimeout;
setTimeout();
These are repeated for the other global timers and the global Date object. Use of Node.js' timers module should also be disallowed similarly to direct access via global (can't recall if it is).
ANYWAY, the point of this is, because we know that Mocha's code will load before any user code, tests, or 3rd-party modules, we can save a reference to those globals. The user is free to do whatever untoward thing they wish to these globals, and Mocha will not be impacted (think Sinon fake timers).
We should be careful to note that this is not intended to avoid malicious code, and shouldn't be used in modules that cannot guarantee the order in which code is loaded. Whether that has broad applicability beyond test runners, I have no idea.
Since it's a rule, I think all we need is an ESLint shareable config--not a plugin.
It might be useful for somebody to reuse our complicated-ass ESLint rules around use of global timers.
These rules, for example, disallow:
but they allow:
These are repeated for the other global timers and the global
Dateobject. Use of Node.js'timersmodule should also be disallowed similarly to direct access viaglobal(can't recall if it is).ANYWAY, the point of this is, because we know that Mocha's code will load before any user code, tests, or 3rd-party modules, we can save a reference to those globals. The user is free to do whatever untoward thing they wish to these globals, and Mocha will not be impacted (think Sinon fake timers).
We should be careful to note that this is not intended to avoid malicious code, and shouldn't be used in modules that cannot guarantee the order in which code is loaded. Whether that has broad applicability beyond test runners, I have no idea.
Since it's a rule, I think all we need is an ESLint shareable config--not a plugin.