Embedding in another extension

Feature request summary

Hey, I think it could be really nice if there was a way to embed lighthouse in another extension.

We’re developing an extension that already utilizes the devtools protocol and opens chrome.debugger.

Currently I was thinking about embedding an audit through the programmatic interface and CLI tool but it would be much nicer if there was a way to (from a Chrome extension context) pass a connected chrome.debugger tabId (or something similar) and embed lighthouse into another extension.

What is the motivation or use case for changing this?

Improving the UI/UX of the extension and being able to use lighthouse directly instead of reusing parts of it or giving users a subpar solution requiring a cli tool.

How is this beneficial to Lighthouse?

Bigger/better ecosystem and motivation for more extensions to get into the “care about site performance” field.

[brendankenny]

The main thing we would want to do is automate maintenance (and not breaking users) as much as possible, so some good tests of the bundled output would be necessary.

maybe we could even always do standalone: 'lighthouse' and move the lighthouse (core) extension to using it. Then the existing test pipeline would make sure things are still working.

We’d have to see if that would be a net improvement in code readability or if it would just make things more complicated than it’s worth, though.

[brendankenny]

It’d really be great not having to keep a fork of the code for this and using lighthouse as an npm module for browser extension development.

Rather than publishing another npm module (with the maintenance and ownership overhead that brings), I think maybe the effort could be put into making the use of lighthouse as an npm module in this way easier.

A Connection is able to be passed into the lighthouse module specifically for allowing use cases like this without requiring users to fork lighthouse. Maybe we could do whatever work is needed to better clean and document the Driver <-> Connection interface so this is easier and more obvious to do. That would improve the core of lighthouse and allow easier downstream usage.

Then it sounds like adding a --standalone (or whatever) flag to ./build/build-bundle.js would let you consume it in the browser (extension) space without maintaining your parallel browserify pipeline. The main thing we would want to do is automate maintenance (and not breaking users) as much as possible, so some good tests of the bundled output would be necessary.