I'm not sure if this has been discussed anywhere on this repo in the past or not - I tried searching for related issues, but didn't really find anything, so apologies if this has already been discussed. I'm wondering if it would be possible to add an optional type parameter to the Node EventEmitter typings to give a standardized way to represent strongly-typed events in Node projects. I'm thinking about making something like this possible out of the box:

interface MyEvents {
  foo: [string, number];
  bar: [boolean];
}
const myEventEmitter = new EventEmitter<MyEvents>();

myEventEmitter.on('bar', eventValue => {
  // eventValue is a boolean
});

// @ts-expect-error - ['foo', false] not assignable to ['foo', string, number] | ['bar', boolean]
myEventEmitter.emit('foo', false);

I've seen similar patterns being used by other projects, using either subclasses of EventEmitter or casting the emitter variable to a custom type in order to achieve the type safety desired. I think it'd be good to have this functionality built into @types/node to avoid projects having to use their own solutions that introduce quirks and inconsistencies between libraries. For example, here's a partial example of how to achieve the above:

interface Events<E extends {[eventName in keyof E]: any[]}> {
  on<K extends keyof E>(eventName: K, listener: (...args: E[K]) => void): this;
  emit<K extends keyof E>(eventName: K, ...args: E[K]): boolean;
  // other EventEmitter methods you care about...
}

const myEventEmitter = new EventEmitter() as Events<MyEvents>;

One concern I have is that event emitters aren't actually limited to emitting known event names. Projects with strongly-typed events often type their emitters in such a way that using an unrecognized event is disallowed, which prevents typo issues, but others are fine with the user emitting custom events on their listeners. Can this be designed to allow typings authors that choice?