Worker.postMessage missing optional options parameter

[dasa]

TypeScript Version: 3.5.0-rc

Search Terms:

Worker MessagePort postMessage

Code

let worker: Worker;
worker.postMessage("test");

let port: MessagePort;
port.postMessage("test");

let either: MessagePort | Worker;
either.postMessage("test"); //  error TS2554: Expected 2 arguments, but got 1.

Expected behavior:

No error. There is no error in 3.4. I'm not sure if this is a bug in the compiler or due to the changes to MessagePort.postMessage in lib.dom.d.ts. Should Worker.postMessage also be updated to have the optional options parameter?

Reference: https://html.spec.whatwg.org/multipage/workers.html#dedicated-workers-and-the-worker-interface

Actual behavior:

error TS2554: Expected 2 arguments, but got 1.

[sandersn]

The problem is that MessagePort has two overloads for postMessage, the second of which has transfer, but transfer isn't optional there. If you change it to optional in the second overload, there's no error.

On the other hand, reading through the spec leads me to this interface:

interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
  [Replaceable] readonly attribute DOMString name;

  void postMessage(any message, sequence<object> transfer);
  void postMessage(any message, optional PostMessageOptions options);

  void close();

  attribute EventHandler onmessage;
  attribute EventHandler onmessageerror;
};

sequence<object> transfer doesn't look optional to me, especially in comparison to the optional PostMessageOptions options on the next line. Perhaps the spec is wrong here?

[fatcerberus]

I'm confused though: despite the non-optional transfer, shouldn't the call with only one argument still match the postMessage(any message, optional PostMessageOptions options) case?

[sandersn]

@fatcerberus I believe the code that creates a signature from a union of signatures is stricter about the number of required parameters in the resulting signature.

Here's a standalone version that's easier to paste into the playground:

interface Terable {
    a,b,c
}
interface PostMessageOptions {
    transferable: Terable[]
}
interface MsgPort {
    postMessage(message: any, options?: PostMessageOptions): void;
    postMessage(message: any, transfer: Terable[]): void;
}
interface Wrkr {
    postMessage(message: any, transfer?: Terable[]): void;
}
declare let either: MsgPort | Wrkr;
either.postMessage('test')

[dasa]

This is a regression from 3.4. Is there a reason that MessagePort was updated but Worker was not?

3.4:

• MessagePort: https://github.com/microsoft/TypeScript/blob/release-3.4/lib/lib.dom.d.ts#L10283
• Worker: https://github.com/microsoft/TypeScript/blob/release-3.4/lib/lib.dom.d.ts#L17165

3.5:

• MessagePort: https://github.com/microsoft/TypeScript/blob/release-3.5/lib/lib.dom.d.ts#L10350-L10351
• Worker: https://github.com/microsoft/TypeScript/blob/release-3.5/lib/lib.dom.d.ts#L17351

The error goes away if Wrkr has the same two signatures as MsgPort.

[fatcerberus]

@sandersn Oh I see - Worker is missing the options overload. My comment above was based on a reading of the spec in which Worker and MessagePort have the same two overloads for postMessage. So yeah, same question as @dasa above me - why is the second overload missing from Worker?

[sandersn]

Looks like @saschanaz just missed it in microsoft/TypeScript-DOM-lib-generator#679. That PR has overrides for MessagePort, ServiceWorker and DedicatedWorkerGlobalScope, but not Worker.

I think it's correct to add it for Worker too, but I want to find out how @saschanaz determined those 3 were the ones that got the overrides before I do.

[sandersn]

Here's the link for Worker. I'll go ahead and add it in TSJS-lib-generator.

[sky0014]

@sandersn Maybe the transfer param should be optional? I found this in the spec:

dedicatedWorkerGlobal.postMessage(message [, transfer ])
dedicatedWorkerGlobal.postMessage(message [, { transfer } ])

And now I still got an error while pass only one param, I have to change it to

worker.postMessage('message', undefined);

that is not a good practice