That's awesome, I'm going to check this out and play with it asap.

Also post it on the summit issue.

Other than test and review this is there anything I can do to help?

Other than test and review this is there anything I can do to help?

One of the next steps is to identify a list of the existing Promise APIs in core that could by updated to make use of this. Not all of them will make sense because not all of them are abortable (e.g. libuv only allows us to cancel file system requests if they have not already been started, for instance). So while we may be able to use AbortController for fs.promises.readFile() (which performs a sequence of discreet read operations) it won't for fs.promises.read() (which performs a single discreet read operation). Once we have a list of APIs for which use of AbortController makes sense, then we need to figure out the best way to incorporate it. Each will have their own set of considerations to address.

Additionally, we should make it possible for custom util.promisify implementations to support AbortController. For instance, I'm playing around with the promisification of setTimeout such that it allows:

const sleep = promisify(setTimeout);
const ac = new AbortController();

sleep(10000, ac);

ac.abort();  // Calls clearTimeout on abort

@jasnell I've split those tasks off into an issue here: #33528 - please feel free to edit that issue as you see fit.

I will start working on these one by one (on weekends mostly) and add tasks as I find them. Feel free to edit it.

I want to be clear that I want to be helpful here so since you took the initiative if at any point any of the things I'm doing are frustrating just tell me and I'll stop and do whatever is helpful to the effort instead. These sorts of ongoing efforts tend to become frustrating in Node.js at times, I want to be sure that I'm not doing any toe-stepping if I can help it.

Initial implementation of EventTarget in #33556. Assuming that one goes through, this PR will be modified such that AbortController.prototype.signal is an instance of EventTarget rather than EventEmitter.

Updated based on the #33556

@benjamingr ... quick note... this is currently extending from NodeEventTarget ... in this, however, the remove listener functions are not used and the only ones we definitely need here are the on/once/addListener in order to achieve the use cases we need for AbortSignal

Marking this ready for review. This does create a new global so technically may be semver-major but I have tested it with existing ecosystem polyfills and haven't seen any breakage at all. Unless there are objections from the @nodejs/tsc, I'd like to handle this as a semver-minor.

It is still experimental and an experimental warning will be emitted the first time an AbortController is created. It is not behind a flag.

@zcbenz

I assume Node's APIs would not be able to take DOM's as well.

Why not? We do not perform the same sort of branding checks the DOM does. We just check that it has a property called "aborted" on it at the moment.

I cannot speak about the other way around though - I would assume node's AbortSignals won't work in DOM APIs.

The TypeScript definitions of Node's AbortSignal must be exactly the same with DOM's one,

I am not sure who maintains the node type definitions - but if the API is different please open an issue and we will fix it. A goal is that developers should have an easier time cancelling things in a universal way and API deltas run counter to that.

But if Node's promise APIs are able to take arbitrary implementation of AbortSignal, then we would be able to replace Node's AbortController with DOM's one completely, and all of the above issues would be solved.

This sounds like a reasonable approach to me.