[topheman]

Closes #1370.

Peer's implementation already accepts an absent id alongside options — constructor(id?: string | PeerOptions, options?: PeerOptions) — and the doc comment says as much: "If no ID is given, one will be generated by the brokering server." But an implementation signature is not callable, and none of the three public overloads admits that combination:

constructor();
constructor(options: PeerOptions);
constructor(id: string, options?: PeerOptions);

So a caller holding an id of type string | undefined — an app that persists its peer id across reloads and reuses it, which is the ordinary reason to pass an id at all — together with a non-default host, port, path or config, has to cast:

new Peer(storedId, options);
//       ~~~~~~~~
// TS2345: Argument of type 'string | undefined' is not assignable to parameter
//         of type 'string'.

The change

-constructor(id: string, options?: PeerOptions);
+constructor(id: string | undefined, options?: PeerOptions);

That is the whole diff. No runtime change — this only publishes a capability the implementation already has.

Why it is safe

Widening a parameter cannot reject a call that used to compile, and the new form does not capture calls that belong to another overload:

• new Peer() still resolves against overload 1.
• new Peer(options) still resolves against overload 2 — PeerOptions is not assignable to string | undefined.
• new Peer(id) and new Peer(id, options) are unchanged.
• new Peer(undefined) now resolves, and is equivalent to new Peer().

npm run check (tsc --noEmit over lib and e2e), prettier --check and npm test all pass.

[codeCraft-Ritik]

he implementation is solid and directly solves the issue with minimal overhead. The test coverage validates the core path effectively. I noted a couple of minor naming and documentation adjustments in the inline comments, but the functional logic is ready to ship.