Rewrite setTimeout / setImmediate behavior #70
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This revises fake-indexeddb's scheduling to work in Jest 27 + jsdom while still remanining performant. (See #69, #67, and related issues.) To review / summarize my current understanding:
process.nextTick
), then it runs the microtask queue (promises andqueueMicrotask
), then it resumes the event loop (and runs the next "macrotask"). (See here and here.)process.nextTick
or microtasks. (See here and here.)I initially thought that I could improve performance by only using
setTimeout
to finish transactions and (to avoidsetTimeout
's slowness) using the microtask queue for everything else. This mostly worked, but I ran into a test failure because microtasks allowed fake-indexeddb database deletion operations to be interleaved with test code, producing out-of-order results. I fixed that by moving database deletion tosetTimeout
, which broke another test invoking database opening, and moving database opening tosetTimeout
broke another test. (See intermediate commits in this PR.)So that approach didn't seem like it would pan out, so I gave up and broke jsdom's sandbox to access
setImmediate
, based on scala-js/scala-js-macrotask-executor#17 and jsdom/jsdom#2729. (It turns out that fake-indexeddb is not the first project to encounter this issue.) This is a dirty hack, but it's documented as a possibility, and it was really easy, and another project is using it.