doc: remove --experimental-abortcontroller documentation

[iam-frankqiu]

According to the docs.

AbortController and AbortSignal support is enabled by default. So I think we should delete this option.

[jasnell]

Deleting a command-line flag is semver-major. It's marked as a non-op, which is appropriate for now. Let's hold off removing it for a while.

[addaleax]

Fwiw, I think removing this from the docs for the current version is fine, but we’re not really getting anything out of removing the flag instead of having it be a no-op.

[iam-frankqiu]

Deleting a command-line flag is semver-major. It's marked as a non-op, which is appropriate for now. Let's hold off removing it for a while.

Is it the right time to remove it now?

[addaleax]

@iam-frankqiu At the risk of repeating what I’ve said before – I don’t think there’s any reason to remove the flag from the source code at any point in time. However, if you want to remove the flag from the documentation, I think we can do that right now.

[iam-frankqiu]

@iam-frankqiu At the risk of repeating what I’ve said before – I don’t think there’s any reason to remove the flag from the source code at any point in time. However, if you want to remove the flag from the documentation, I think we can do that right now.

Thank you. What I want to do is just make node.js simpler and cleaner.

[dnalborczyk]

any reason to remove the flag from the source code at any point in time

@addaleax I think that something flagged as experimental should include the flag itself as being experimental, meaning it might just disappear at any given time. I really hope the flag is not being carried around forever, this makes no sense.

speaking of experimental: I get the feeling that the notion of experimental has lost its meaning in the node.js project - meaning most the time it is being treated as untouchable and semver major.

that's not what I understand of "experimenting". experimenting means I can break things, hence we flag it. "be aware! it might (and will) break!" but I think people have gotten used to the fact that node.js experimental stuff does not break. when I run any given project of mine I get more or less experimental warnings of some 3rd party modules using node.js built-ins.

if an application developer is using an experimental flag, I'm pretty sure it's easy to remove, and was set with the same mindset of being eventually removed. heck, most (if not all) of the companies don't even want you to use any "experimental" flags in production. because the word alone sounds brittle and unstable.

[aduh95]

speaking of experimental: I get the feeling that the notion of experimental has lost its meaning in the node.js project - meaning most the time it is being treated as untouchable and semver major.

I can think of several recent changes to some Node.js experimental API changes, but let's not debate on this. I think Anna's point is:

1. it's not because it's experimental that it has to break.
2. keeping a no-op flag costs virtually nothing, removing it is a breaking change with no benefit.

Consider this: keeping the flag allows users to use globalThis.AbortController on Node.js 14.x while keeping full compatibility with Node.js 16.x+. Removing it would make this impossible (or rather needlessly over complicated). If you feel strongly, consider opening another PR when Node.js 14.x has reached EOL.

[addaleax]

To add on to what @aduh95 said –

most (if not all) of the companies don't even want you to use any "experimental" flags in production. because the word alone sounds brittle and unstable

Great, then it sounds like this is working as it should?

[addaleax]

Also, for some more context, we specifically put this into our Collaborator guide to avoid having this discussion over and over again:

Avoid Runtime Deprecations when an alias or a stub/no-op will suffice. An alias or stub will have lower maintenance costs for end users and Node.js core.

[aduh95]

@jasnell are you still -1 on this now that the change is doc-only?

[jasnell]

Landed in 24292b4