@connorjclark @paulirish I do not seem to find this in the release on npm, do I need to do anything extra to have it included into the npm package? I also saw that there are some reports include into the distribution such as latest-run-oom, are these intended? https://www.npmjs.com/package/lighthouse?activeTab=code

These reports do not seem to present in v12 https://www.npmjs.com/package/lighthouse/v/12.8.2

We only publish a few things from the dist folder (where our build artifacts go). We attempt to keep our npm package size minimal, so I'd rather not include this on npm since it's huge and not something any npm user needs (other than us).

(from .npmignore)

# generated files needed for publish
dist/**
!dist/report/standalone.js
!dist/report/flow.js
!dist/report/bundle.esm.js

I suggest manually creating this bundle and copying (vendoring) it into the mcp repo. You could write a few lines of bash to automate the sync.

These reports do not seem to present in v12 npmjs.com/package/lighthouse/v/12.8.2

The latest npm publish was borked, I pinged @paulirish about it.

That makes sense. I currently vendor the bundle and CodeQL reports the following security issues https://github.com/ChromeDevTools/chrome-devtools-mcp/pull/831/checks?check_run_id=63222750490 and some look like thez might be actionable. I think http-link-header library might not be escaping quotes correctly, csp_evaluator might not be handling wildcards correctly, data: and vbscript: schemes might not be handled in one place, and some misdiagnosed prototype pollution? Do you know if all of these are safe to ignore in the context of Lighthouse use case?

The latest npm publish was borked, I pinged @paulirish about it.

yup. i messed it up! sorry. fixed in v13.0.3 which just went out.

I think http-link-header library might not be escaping quotes correctly,

Not sure about this one. My intuition is that it's fine. https://www.npmjs.com/package/http-link-header says it follows the RFC. Sadly the gh repo is down now, so we can't look at the test suite. But even if escapeQuotes() doesnt escape a backslash.. i'm not worried.

csp_evaluator might not be handling wildcards correctly

safe to ignore because CSP only allows a single wildcard in addition to :* for any port

data: and vbscript: schemes

yeah. this is ignorable. this is for link-text audit

the recommendation is wrong. given what we're doing there.

and some misdiagnosed prototype pollution?

eh. this is in lighthouse's core/config/config-helpers.js in the _mergeConfigFragment method. (Where we resolve the default config against a user's runtime config)

I don't really see an attack for how you pollute your own config. But.. shrug.