Unable to access base Event properties from CloseEvent, ErrorEvent & MessageEvent for WebSocket

[eXhumer]

Bug Description

MessageEvent inherits Event and is supposed to provide the properties of Event such as Event.type and Event.timeStamp to MessageEvent. However, any class inheriting Event (CloseEvent, ErrorEvent & MessageEvent) fails to make any of the base properties accessible and causes the typescript compiler to fail unless MessageEvent type gets replaced by any when trying to access the base event properties.

Reproducible By

The following code is successfully compiled by tsc compiler.

const ws = new WebSocket('ws://localhost:8080');

ws.onmessage = (ev) => {
  const e = ev as any;
  console.log(e.type);
  console.log(e.defaultPrevented);
  console.log(e.cancelable);
  console.log(e.timeStamp);
};

The following code will throw an error while trying to compile with tsc due to Property '' does not exist on type MessageEvent<any>.

const ws = new WebSocket('ws://localhost:8080');

ws.onmessage = (e) => {
  console.log(e.type);
  console.log(e.defaultPrevented);
  console.log(e.cancelable);
  console.log(e.timeStamp);
};

Expected Behavior

Base properties of Event class accessible from inherited classes.

Logs & Screenshots

None

Environment

macOS 15.1 Beta (24B5035e), node v22.6.0, undici v6.19.8

Additional context

[mcollina]

@KhafraDev @Uzlopak @panva wdyt?

[panva]

I don't follow, the types are set up to extend Event all the same.

undici/types/websocket.d.ts

Lines 85 to 89 in cab6011

	interface CloseEvent extends Event {
	readonly code: number
	readonly reason: string
	readonly wasClean: boolean
	}

undici/types/websocket.d.ts

Lines 135 to 141 in cab6011

	interface ErrorEvent extends Event {
	readonly message: string
	readonly filename: string
	readonly lineno: number
	readonly colno: number
	readonly error: any
	}

undici/types/websocket.d.ts

Lines 104 to 120 in cab6011

	interface MessageEvent<T = any> extends Event {
	readonly data: T
	readonly lastEventId: string
	readonly origin: string
	readonly ports: ReadonlyArray<typeof MessagePort>
	readonly source: typeof MessagePort | null
	initMessageEvent(
	type: string,
	bubbles?: boolean,
	cancelable?: boolean,
	data?: any,
	origin?: string,
	lastEventId?: string,
	source?: typeof MessagePort | null,
	ports?: (typeof MessagePort)[]
	): void;
	}

[eXhumer]

I think the problem lies in undici/types/patch.d.ts, where the Event type is defined with the following.

undici/types/patch.d.ts

Lines 25 to 26 in 5f81898

	export type Event = typeof globalThis extends { Event: infer T }
	? T

The { Event: infer T } infers the type as any.

[KhafraDev]

Some history of why it was added: #1740

Is there an easy workaround? Is this even needed anymore? @Ethan-Arrowood @andrewbranch

[eXhumer]

I did a bit more digging, I think I figured out what the exact issue is. With the type inference being used, typescript infers the following Event type from node_modules/typescript/lib/lib.dom.d.ts instead of the correct type from the same file.

declare var Event: {
    prototype: Event;
    new(type: string, eventInitDict?: EventInit): Event;
    readonly NONE: 0;
    readonly CAPTURING_PHASE: 1;
    readonly AT_TARGET: 2;
    readonly BUBBLING_PHASE: 3;
};

Even if you use @types/node package to provide types, unless you disable the default DOM types provided by typescript, typescript infers the type from typescript package rather than @types/node package.

If you try accessing the readonly values, typescript will incorrectly think they are actually there and not complain when trying to access a non-existent property.

import { WebSocket } from 'undici';
import { WebSocketServer } from 'ws';

const wss = new WebSocketServer({ port: 8080 });

wss.on('connection', function connection(ws) {
  ws.send('something');
});

const ws = new WebSocket('ws://localhost:8080');

ws.onmessage = e => {
  console.log('e.NONE', e.NONE);
  console.log('e.CAPTURING_PHASE', e.CAPTURING_PHASE);
  console.log('e.AT_TARGET', e.AT_TARGET);
  console.log('e.BUBBLING_PHASE', e.BUBBLING_PHASE);
  console.log('e.data', e.data);
};

process.on('SIGINT', () => {
  console.log('Closing WebSocket server');
  wss.close();
  process.exit();
});

Console output

➜  node-network-app git:(main) ✗ yarn tsc
yarn run v1.22.22
$ /Users/exhumer/Projects/node-network-app/node_modules/.bin/tsc
✨  Done in 0.75s.
➜  node-network-app git:(main) ✗ yarn ts-node src/index.ts
yarn run v1.22.22
$ /Users/exhumer/Projects/node-network-app/node_modules/.bin/ts-node src/index.ts
e.NONE undefined
e.CAPTURING_PHASE undefined
e.AT_TARGET undefined
e.BUBBLING_PHASE undefined
e.data something
^CClosing WebSocket server

[eXhumer]

I have found a fix by getting rid of the Event type provided in patch.d.ts. typescript now correctly imports the DOM Event type from typescript/lib/lib.dom.d.ts. If you want to use the types provided by @types/node package instead for whatever reason, you can disable the default DOM imports from typescript config and then getting rid of the Event type provided in patch.d.ts.

[eXhumer]

undici is currently at node@>=18.17 after support for node@<18.17 was dropped with the following commit. Based on the comments from @KhafraDev here, this patched Event type seems to have been added for support for node@<=16, which is no longer supported. I am not sure if there is any point in the patched Event type at the very least.

patch.d.ts was added in as a part of this commit when the supported engine was node@>=12.18.

[eXhumer]

Looking into PR #1690, there was a lengthy discussion with SimenB and other members about the DOMException type and it's availability.

After which a new PR (#1762) was later opened which added the patch.d.ts as part of a type fix.

[eXhumer]

Confirmed issue to be fixed with the Event & EventTarget removed from patch.d.ts and removing all references to related imports.