Skip to content
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

performance.mark doesn't exist in node@16 when using jsdom globals #420

Closed
msluther opened this issue Feb 1, 2022 · 5 comments
Closed

Comments

@msluther
Copy link

msluther commented Feb 1, 2022

What did you expect to happen?

performance.mark is a function

What actually happens

performance.mark is undefined

How to reproduce

Minimal repro is available here: https://github.com/msluther/sinon-timers-jsdom-bug

Effectly though it's just this in node@16:

require('global-jsdom/register'); // This setups up jsdom and copies properties from `window` up to global, including a minimal Performance type
const sinon = require('sinon');
global.performance.mark(); // works
sinon.useFakeTimers();
global.performance.mark(); // throws as `mark` is now `undefined`

This is related to this issue: #394

From my comment on that issue:

Hrm. So, the fix works but makes the assumption that the functions on global.Performance.prototype are a superset of global.performance.* functions. This is currently not the case when using node@16 and jsdom. jsdom is injecting a global.Performance object based on the minimal W3C spec for hr-time.

This isn't necessarily a bug with either library, but feels like a gap between the two.

However, @sinon/fake-timers ends up replacing a good global.performance.mark with undefined in this situation. Should the code here use both prototypes to make sure this is the case or maybe prefer the global.performance over global.Performance?

The work around that I posted above still works in this case as long as its injected prior to sinon & jsdom, so I'm not blocked by any means, but just requires making sure that happens in my tests everywhere.

@benjamingr
Copy link
Member

While it's not strictly a bug I think it's very reasonable to support this use case and the fix shouldn't be too hard.

@zbyte64
Copy link
Contributor

zbyte64 commented Aug 12, 2023

This is currently impacting me, but on node v18. What would an acceptable unit test be for this?

@zbyte64
Copy link
Contributor

zbyte64 commented Aug 12, 2023

From my own manual testing, swapping the order here:

if (hasPerformancePrototype) {
return _global.Performance.prototype;
}
if (hasPerformanceConstructorPrototype) {
return _global.performance.constructor.prototype;
}
is enough to resolve the issue for me anyways.

@benjamingr
Copy link
Member

@zbyte64 feel free to open a PR

@fatso83
Copy link
Contributor

fatso83 commented Aug 13, 2023

PR merged 🥳 Thanks a bunch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants