process: make `process.nextTick()` awaitable

[XadillaX]

For code changes:

• [x] Include tests for any bug fixes or new features.
• [x] Update documentation if relevant.
• [x] Ensure that make -j4 test (UNIX), or vcbuild test (Windows) passes.

[XadillaX]

I don't think this should exist, it's basically "run at the end of the microtask queue after the next tick", which is not an idiom anyone should be reaching for.

It just for await things for next tick (or anything else in next event loop).

So:

const deferred = createDeferredPromise();
setTimeout(() => { derferred.resolve; }, 0);
await deferred.promise;

// .. do  something in next (or next next ...) tick

may be OK too.

[targos]

What use case would be solved by this that cannot work with setImmediate ?

import { setImmediate } from 'timers/promises';
await setImmediate()

[XadillaX]

What use case would be solved by this that cannot work with setImmediate ?

import { setImmediate } from 'timers/promises';
await setImmediate()

I mean just like setImmediate(), we make process.nextTick() promisified too.

[aduh95]

This is similar to Promise.resolve(arg).then(cb), correct? If so, I think we should not encourage users to use a Node.js specific API. Related discussion: https://github.com/nodejs/node/issues/19617 (as said in this thread, process.nextTick is already awaitable, technically)

[benjamingr]

It just for await things for next tick (or anything else in next event loop).

Note that nextTick is opposite of "in the next tick". It's "in the current tick but after all synchronous code and previously queued nextTicks finished".

setImmediate is the opposite of immediately - it runs in the next tick 😅 .

Their naming is pretty confusing. setImmediate is already promisified and people can use that to await for I/O to run.

[benjamingr]

@jasnell technically #1 and #2 have different timings as well since they don't run on the same queue which is exactly the sort of implementation detail users shouldn't care about.

[jasnell]

Yep. Making nextTick awaitable just makes things even weirder.

[joyeecheung]

I am -1 as well..I think this would just make things even more complex for our users, with no obvious gains

[wzhouwzhou]

As just an opinion from userland, a general -1 to bloating up and adding unnecessary complexity for minimal gain and usage. In terms of performance, this PR introduces additional quaint checks that hog the EL and you can always use any of the aforementioned solutions for some specialised use cases. Copying in @tbnritzdoge as well who is also familiar with async overhead.