wondering if changing on/once to accept a regex would be better api

I think some other method is desired due to the signature differences (possibly unavoidable for typescript explosion constraints? Crdp events already pushed the envelope before). You need to know what event happened for any function that can be invoked for more than 1 event type.

I'm open to other names other than onAny. The phrase looks ugly to me, but I don't have amazing suggestions, onEvery perhaps?

I think some other method is desired due to the signature differences (possibly unavoidable for typescript explosion constraints? Crdp events already pushed the envelope before). You need to know what event happened for any function that can be invoked for more than 1 event type.

hmm right, the callback does need methodName to disambiguate the events, since the event object themselves don't have that.

I did the easy part of the type change:

/**
   * Bind listeners for protocol events.
   * @template {keyof LH.CrdpEvents} E
   * @param {E|RegExp} eventName
   * @param {(...args: LH.CrdpEvents[E]) => void} callback
   */
  on2(eventName, callback) {
    if (eventName instanceof RegExp) {
      // ...
    } else {
      this._session.on(eventName, /** @type {*} */ (callback));
    }

    this.on2('Network.dataReceived', e => e.dataLength);
    this.on2(/./, e => e); // e is union of all. totes useless.
  }

somehow this work, idk why E=RegExp results in e being the union of all events

I did the easy part of the type change:

That still doesn't seem like a usable type signature though, or is that what you meant by the easy part? :)

Taking a step back, I'm not really convinced that a regex-based method with a polymorphic signature is an easier API to understand and use than onEvery. for onEvery you get the benefit of narrowing the type as you filter in usage and worst case scenario it devolves to regex again and first line of that is if (!/the pattern/.test(event.method)) return with the benefit of human readable typedef

Taking a step back, I'm not really convinced that a regex-based method with a polymorphic signature is an easier API to understand and use than onEvery. for onEvery you get the benefit of narrowing the type as you filter in usage

I was imagining usages of the "regexp" api would do the same.

and worst case scenario it devolves to regex again and first line of that is if (!/the pattern/.test(event.method)) return with the benefit of human readable typedef

ah, yea, ok so basically the code would end up being the same. nvm on the regexp.

onAnyProtocolMessage instead of onAny?

onAnyProtocolMessage instead of onAny?

SGTM 👍

Since holding off for release I played around with a few more ideas, WDYT about this @connorjclark?

diff --git a/lighthouse-core/fraggle-rock/gather/session.js b/lighthouse-core/fragg
le-rock/gather/session.js
index dd15f9535..db3b27b6c 100644
--- a/lighthouse-core/fraggle-rock/gather/session.js
+++ b/lighthouse-core/fraggle-rock/gather/session.js
@@ -26,6 +26,11 @@ class ProtocolSession {
     };
     // @ts-expect-error - It's monkeypatching 🤷<U+200D>♂️.
     session.emit[SessionEmitMonkeypatch] = true;
+
+    /** @type {LH.Gatherer.FRProtocolSession['on']} @param {Array<*>} args */
+    this.on = (...args) => args.length === 1 ?
+      session.on('*', args[0]) :
+      session.on(args[0], args[1]);
   }

   /**
diff --git a/types/gatherer.d.ts b/types/gatherer.d.ts
index 9fc0dd197..4d81705a8 100644
--- a/types/gatherer.d.ts
+++ b/types/gatherer.d.ts
@@ -17,6 +17,7 @@ declare global {
       getNextProtocolTimeout(): number;
       setNextProtocolTimeout(ms: number): void;
       on<TEvent extends keyof LH.CrdpEvents>(event: TEvent, callback: (...args: LH.CrdpEvents[TEvent]) => void): void;
+      on(callback: (args: LH.Protocol.RawEventMessage) => void): void;
       once<TEvent extends keyof LH.CrdpEvents>(event: TEvent, callback: (...args: LH.CrdpEvents[TEvent]) => void): void;
       onAnyProtocolMessage(callback: (payload: LH.Protocol.RawEventMessage) => void): void
       off<TEvent extends keyof LH.CrdpEvents>(event: TEvent, callback: (...args: LH.CrdpEvents[TEvent]) => void): void;

Usage

// Listen to a specific event.
session.on('Page.frameNavigated', event => console.log(event));
// Listen to *all* events.
session.on(({method, params}) => console.log(method, params));

I'll cast my vote for onAnyProtocolMessage (or whatever name) rather than overloading on:

• least surprise (on still behaves like the typical EventEmitter.on)
• .on(callback) kind of breaks the self-documentation of .on(eventName, callback) :)
• overloading is (usually) broken for a lot of modern TypeScript functionality, e.g. param/tuple manipulation, call/apply type checking, etc and conditional types are the recommended solution if really needed (e.g adding types to an existing overloaded API that can't be changed)

Isn't this going to be called in like three places? Do we need a shorthand for it?

Any other voters out there? The arguments are above, LMK by tomorrow at 10am CDT

https://fast-poll.com/poll/4c080449

Alright the voters have spoken! Uncontested win for onAnyProtocolMessage, sorry @connorjclark

that's what I voted for doe

that's what I voted for doe

😑...

bro, then why 🎉 my proposal for what I thought your request was!? time on life I'll never get back 😆

i'm an irrational voter sry