process: make process.nextTick() awaitable

[XadillaX]

For code changes:

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

[mscdex]

Suggested change

	const defered = createDeferredPromise();
	const deferred = createDeferredPromise();

[XadillaX]

done

[mscdex]

I think this could be simplified without the destructuring assignment above this line along with:

Suggested change

	callback = nextTickDefaultCallback.bind(undefined, resolve);
	callback = nextTickDefaultCallback.bind(undefined, deferred.resolve);

[XadillaX]

done.

[devsnek]

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.

[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: #19617 (as said in this thread, process.nextTick is already awaitable, technically)

[benjamingr]

I'm also -1, if you want a version of proces.nextTick that returns a Promise you can just await null or await Promise.resolve().

If anything ideally we'll deprecate process.nextTick in favour of the web standard queueMicrotask

[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.

[jasnell]

I'm generally -1 on this. There are already a number of ways of doing similar deferals...

await Promise.resolve();

// or 

await new Promise((resolve) => process.nextTick(resolve));

// or, with slightly different timing semantics...

const { setTimeout } = require('timers/promises');
await setTimeout();

Let's leave process.nextTick() unchanged. We don't need Promise APIs for everything.

[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.

[Vetlix]

Removal of all edits here

[jasnell]

Think it's likely safe to close this one at this point ;-)