Add ability to skip some errors inside the code

[klarkc]

Feature request summary

Testing tools like eslint and instanbul have comment marks to tell the test runner to ignore some or many errors in the next sentence or in a range of lines in the code. Lighthouse should have it too. I can help with suggestions and feedback.

Here are some examples of ignore comments:

// eslint-disable-next-line no-console
console.log('foo')

/* eslint-disable */
console.log('foo')
console.log('bar')
/* eslint-enable */

/* istanbul ignore next */
if (foo === 'bar') console.log('foobar')

with html

<!-- eslint-disable vue/no-v-html -->
<v-icon
      v-if="icon"
      right
      v-html="icon"
/>
<!-- eslint-enable vue/no-v-html -->

What is the motivation or use case for changing this?

I am using lighthouse as part of my CI/CD pipeline, with lighthouse-ci. The lighthouse step validates every new added line of code, and the developer must fix the issues or add skip configuration for the whole page in that URL.

Sometimes, in specific contexts, auditions results in "false-fails" because user perception is subjective. One example is the color contrast rule, which is very restrict, but as this post issues in Myth 1, the metric has issues with high luminance colors.

How is this beneficial to Lighthouse?

It reduces time-consuming adjusts in config files that will improve lighthouse developer experience, allowing it to be used more effectively and efficiently during development process.

Some related issues that this change could help with:

GoogleChrome/lighthouse-ci#208
GoogleChrome/lighthouse-ci#511

[paulirish]

It's a cool idea, but the short version is we don't think it makes much sense for us.

Our errors-in-console audit does have some configurability so one can ignore items. #9480

However we don't have these kinds of options for all audits. GoogleChrome/lighthouse-ci#525 tracks filtering by URL.

And lhci allows writing maxLength assertions: https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md#properties provides control for specifying expected numbers of results.

But yeah a lot of the things we flag can't be mapped back to a specific code location. And also we analyze production assets, which probably should had comments minified out already.

So we're not gonna pursue this. Appreciate the well-written feature request though!