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
I wanted to ask, what is the stance of the team on providing a way to set mocks on global timing-related APIs that can be locked to a given scope? For example:
importFakeTimersfrom"@sinonjs/fake-timers";consttimer=FakeTimers.install({toFake: ['Date']});functionblockA(){returntimer.useSystemTime(0,()=>`Current timetstamp is ${Date.now()}`);}functionblockB(){return`Current timetstamp is ${Date.now()}`;}// Run concurrently, blockA returns timestamp of 0,// while blockB returns actual timestamp
This sounds very interesting indeed, and I did go to checkout the example vitest sandbox. I only saw a "Upgrade Required" in the output, which might explain the failing test 😄 I did catch the gist of the concept though, and I absolutely find the concept of keeping async contexts worth considering.
Are there anyone outside of Node doing something similar to AsyncContext?
It would be fine to have a node-only feature to start out.
In my case specifically, I'm writing tests for a project built on Workers, but in that case, you still have access to AsyncContext because of the platform's Node Compatibility Mode.
Hi y'all!
I wanted to ask, what is the stance of the team on providing a way to set mocks on global timing-related APIs that can be locked to a given scope? For example:
This is related to vitest#5750
The text was updated successfully, but these errors were encountered: