blog/NodeJS-visualizing-nextTick-and-promise-queues

[giscus[bot]]

blog/NodeJS-visualizing-nextTick-and-promise-queues

We're breaking down the nextTick and Promise queues in the Node.js event loop. Learn how they function and determine which queue finishes first.

https://www.builder.io/blog/NodeJS-visualizing-nextTick-and-promise-queues

[jaabiri]

I ran the provided code on a Windows machine (Windows 11) with Node.js v22, and I observed a different output than expected. Here’s what I got:

this is Promise.resolve 1
this is Promise.resolve 2
this is Promise.resolve 3
this is process.nextTick 1
this is process.nextTick 2
this is process.nextTick 3
this is the inner next tick inside Promise then block
this is the inner next tick inside next tick

The ordering of process.nextTick and Promise.resolve seems to have changed compared to the behavior described in the article.

Has there been a change in the event loop scheduling for nextTick vs Promise.resolve in Node.js v22, or is this a platform-specific difference on Windows?

I'd love to understand if this is an intentional change or a Windows-specific behavior. Any insights would be appreciated!

---

[RicardoYare]

I am newbie in Node.JS so take what I say with a grain of salt, but apparently what I have found is that it has to do with the difference between using Common JS and ES Modules.

The official documentation says:

“This is because the ES Module being loaded is wrapped as an asynchronous operation, and thus the entire script is actually already in the promises microtask queue. So when the promise is immediately resolved, its callback is appended to the microtask queue. Node.js will attempt to clear the queue until moving to any other queue, and hence you will see it outputs bar first.”

https://nodejs.org/en/learn/asynchronous-work/understanding-setimmediate

So basically, if you change from index.mjs to index.js the example from the article works as intended.