Thanks @adamraine ! sounds good I'll start breaking it up.

The feedback I am seeking at this stage is if this method extraction pattern feels reasonable to other driver API consumers as well (that's YOU 😄). The primary goal of this structure is to avoid a 2nd monolithic driver and provide a way of sharing complex protocol interaction in a composable way. I've converted a few of the usage examples so you can get a feel for how it changes driver usage.

This move seems fine. Driver became kind of a utility dumping ground, but part of the reason the moves here are so clean is because a lot of the functions in there are already composable. To me the main issue with Driver (beyond just overdue general cleanups) is the complicated state that crept in with multi target and autoattach support (e.g. #7608 (review)). With that (hopefully) easier to follow and kept separate when built on top of sessions, the question here seems mostly one of should the utility functions be in one namespace or split up into multiple ones.

Multiple namespaces is usually(?) better, but OTOH when it's hard to come up with a name for a module containing getRequestContent() and scrollTo(), that means it'll also be hard to think of the name later when trying to find them and I'll probably just search for protocol names like I do today to see if we have any existing code using a particular command :) It's not perfect, but we also aren't making a puppeteer API in here for anyone, just collecting methods used in more than one place or enshrining things so the next person doesn't have to do the research, so either way seems fine, really.

I think the real ergonomic questions aren't going to be clear until things settle a little bit, so I'm very happy to defer on that. The things I'm really liking in here are getting rid of the cruft (I notice querySelector() and lh-element are finally getting axed :) and some of the clarifications (e.g. the much more clear emulation/throttling distinction).

• I'd also love to see some of the gather-runner-specific logic pulled out (or at least considered for pulling out) of some of these and into the caller. e.g. should registerRequestIdleCallbackWrap really do nothing if settings.throttlingMethod !== 'simulate' or should gather-runner just not call it in that case?
• People may have good arguments for not doing this (and it's probably a case-by-case call regardless), but at least my instinct with single-caller functions like getScrollPosition is to move them back to the caller rather than have them in a utility collection, and functions like enableRuntimeEvents don't seem like they even need a function for them at all.

I'd also love to see some of the gather-runner-specific logic pulled out (or at least considered for pulling out) of some of these and into the caller. e.g. should registerRequestIdleCallbackWrap really do nothing if settings.throttlingMethod !== 'simulate' or should gather-runner just not call it in that case?

People may have good arguments for not doing this (and it's probably a case-by-case call regardless), but at least my instinct with single-caller functions like getScrollPosition is to move them back to the caller rather than have them in a utility collection, and functions like enableRuntimeEvents don't seem like they even need a function for them at all.

That was also on my target list next (sort of) :) My plan for gather-runner extraction was to eliminate these individual tiny ones and instead restructure them into the shared parts of gathering, but if we're already on the same page, then I'll probably just tackle those when I get to that splitting out for discussion.

Everything substantive in this PR has landed 🎉