Discuss planning a long-term renaming of `process.nextTick()`

[Fishrock123]

This continues to confuse people and we should probably do something about it since the current behavior is unlikely to change back and because the expected behavior is now actually found in setImmediate().

Doing this would be a very long-term thing. process.nextTick() has very significant ecosystem usage.

I'm thinking we would created a differently named alias but not formally document it for an LTS cycle or so. That way, when we document it people can switch over in a way that won't hurt older versions or require shims.

It's not exactly the "cleanest" way forward but there is little else we can do. But, I think we should do something about it for the future.

I'm not sure what we would call it though. Maybe something like callBeforeIO? Idk yet.

@nodejs/collaborators

[jasnell]

I understand the reasons but I'm extremely unsure we should do anything here and it would likely be the Bikeshedding Event of the Year to come up with a good name (the name 'process.beforeTick()` might actually be appropriate ;-) ... ). My key concern would be that a rename would cause even more confusion than what we have currently and would have very little actual benefit. I don't disagree that it's worth discussing tho.

[indutny]

Let's leave it as it is.

[cjihrig]

+1 to leaving as is.

[Trott]

If all that's being proposed is to add a less confusingly-named alias and leave it at that for a long time (and possibly forever), then I'm OK with that.

"Renaming" implies deprecation or removal, It might not be useful to think about if (much less, when) to deprecate it at this point.

[Fishrock123]

Right. I'm thinking the best way forward for a longer-term thing would be to add an alias without documenting or promoting it, have it sit for like an LTS (maybe two even), and then start seeing if we can make a move over.

We haven't done something like this before, so I think at the very least It would be useful to think about it.

[vkurchatkin]

-1. Too late for that. Maybe we can undocument it and think of something better. Maybe exposing v8's enqueueMicrotask is an option

[trevnorris]

@vkurchatkin Exposing the microtaskqueue is only an option once we have the V8 API necessary to hook in domains, etc. Once that's there, I'm all for exploring the option.

[jasnell]

Given the -1's on this, can this be closed?

[lostthetrail]

As node continues to grow in use, the brain mapping of "actual functionality" to name, is un-required additional complexity for new users.

It's a known sharp edge in the code, why not start down the path of dulling it? What is the downside to adding in properly descriptive names, which enable people to start phasing out the usage of the confusing ones?

[calvinmetcalf]

@lostthetrail the very significant usage is the downside meaning the old name will likely never be removed. The best idea any one here has come up with is to create a less badly named alias (though the exact idea for an accurate name is still tbd), if we go down that road there is a good chance we end up in a worse case compared to where we started with both names being used and people being even more confused.

[sam-github]

The only way forward I can think of is to find a better name (this is hard), and then make it an alias, and backport the alias to all LTS node versions. Without the backport, we can't write portable code. Once it was available everywhere, we could start to deprecate it in newer major releases, and after a couple years it would be fixed. Lots of work, and it all starts with a better name.

Or we could just switch the implementations of setImmediate and nextTick... since they do what the other's name claims to do, but that's a pretty incompatible change.

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. Better yet, maybe open a PR. I'm just tidying up and not acting on a super-strong opinion or anything like that.