docs: add link to gist for using lighthouse audits directly #10480
Conversation
connorjclark
requested review from
paulirish
and removed request for
patrickhulce
|
(I overrode the auto-assignment b.c. this is something me and paul are working on. but feel free to comment @patrickhulce :) |
|
|
||
| const fs = require('fs'); | ||
|
|
||
| const makeDevtoolsLog = require('lighthouse/lighthouse-core/test/network-records-to-devtools-log.js'); |
There was a problem hiding this comment.
warning: this was written to create devtools logs good enough for tests, not necessarily good in and of themselves :)
The intent was to keep improving the generation but I think there's only been a need for that once.
| }; | ||
| } | ||
|
|
||
| async function run() { |
There was a problem hiding this comment.
let's allow @prateekbh to use this file as a lib.
i'm thinking we do a
module.exports = function analyze(arrayOfBundleAndMapCombos){ ...so basically move L55-60 and L78 out into an index.js file or whatever.
There was a problem hiding this comment.
We discussed offline, but we do not want to have this file be a module that is used by a client. We don't want to support such an interface. This is just an example recipe. Also it's too early to know what the requirements will be exactly :)
There was a problem hiding this comment.
We discussed offline, but we do not want to have this file be a module that is used by a client. We don't want to support such an interface. This is just an example recipe. Also it's too early to know what the requirements will be exactly :)
yeah, that makes sense, but maybe still consider leveraging auditMode in the recipe since absorbing the complexities of running audits is pretty much its purpose.
I don't know how gross it'll be to use this way, but possibly less than dealing with audit products directly :)
There was a problem hiding this comment.
@prateekbh connor convinced me its fine to keep this recipe super hardcoded because anyone we expect to use it is gonna have to do some work. :).
but basically feel free to take the file and do the changes i suggested on your own.
if you continue using this and it makes sense for us to offer this as a real supported API, we can do that (eg. lighthouse.analyzedJSBundles(arr)), but it's too early right now to commit to that.
and please chat with us as you play around with this. :)
There was a problem hiding this comment.
Sounds good to me. Will get in touch
|
|
||
| // Run a byte-efficiency audit directly. | ||
| const duplicatedJavascriptResult = | ||
| await DuplicatedJavascript.audit_(artifacts, networkRecords, context); |
There was a problem hiding this comment.
don't you still want to call byte-efficiency audits with .audit()? Most people probably wouldn't want the intermediate result.
There was a problem hiding this comment.
don't you still want to call byte-efficiency audits with
.audit()? Most people probably wouldn't want the intermediate result.
speaking of which, we do have the slightly awkward thing that audits return an LH.Audit.Product, then it's Runner that calls Audit.generateAuditResult() to turn that into an LH.Audit.Result (which is what you might expect going off of LHR types). @paulirish's idea of a lib for this might be able to hide that away, though (it could really just generate the artifacts and call -A mode).
There was a problem hiding this comment.
don't you still want to call byte-efficiency audits with .audit()? Most people probably wouldn't want the intermediate result.
Don't know yet - maybe not. Use case is still nebulous. I deferred it for now because ByteEfficienyAudit.audit requires a trace.
i was originally thinking |
| }; | ||
| } | ||
|
|
||
| async function run() { |
There was a problem hiding this comment.
@prateekbh connor convinced me its fine to keep this recipe super hardcoded because anyone we expect to use it is gonna have to do some work. :).
but basically feel free to take the file and do the changes i suggested on your own.
if you continue using this and it makes sense for us to offer this as a real supported API, we can do that (eg. lighthouse.analyzedJSBundles(arr)), but it's too early right now to commit to that.
and please chat with us as you play around with this. :)
Can I interest you in a gist, then? Or an entry in https://github.com/GoogleChrome/lighthouse/blob/master/docs/hacking-tips.md? Or a stackoverflow self-answered post? :) This is still really rough, will break if the artifacts needed for those still-being-written audits change, and if I'm reading the room correctly no one wants to own building this into a real example (at least until we have user feedback). It doesn't fit well with the other recipes fragility- or quality-wise. |
okay yeah. sounds good. a gist that's linked from hacking-tips! |
connorjclark
changed the title
I've had to do similar things a few times for personal tools I've written leveraging Lighthouse. There's actually a legit use case now (internal, idk public so I won't say more) so here's a recipe showing how.
Surely there would be more needed to run other audits directly, however I focused on the current use case at hand. Could add more examples if someone expresses interest.