deps: update axe-core to 3.4.1

[jayaddison]

Summary
Updates axe-core==3.4.1 following its release on 2019-12-18 (release tag).

[jayaddison]

Upgrading the dependency here pushes the lighthouse-dt-bundle.js file size over the configured limit. I'm not sure what the policy on increasing that is, so I'll leave the PR as-is.

Error snippets from the build log:

 FAIL  ./dist/lighthouse-dt-bundle.js: 401.52KB > maxSize 400KB (gzip)
...
The command "yarn bundlesize" exited with 1.

[jayaddison]

@brendankenny @patrickhulce From the test failures in this PR, upgrading axe-core to 3.4.0 pushes the lighthouse devtools bundle over the configured size limit of 400KB.

I'm not going to push any commits which change build limits, so was wondering if there's a good way to resolve the failure in order to unblock the version bump?

[patrickhulce]

Thanks very much for the PR @jayaddison!

Hm, that's a fairly substantial increase for 3.4.0, an extra ~60KB minified script (13KB gzipped) :/

Is there something in this release particularly compelling to warrant the increase? If not, I'd be inclined to skip and see if we can require in smaller pieces or work to find some bundle size wins in axe-core for the next version.

Just noting we also need to mark aria-roledescription as unused or create an audit for it before landing.

[jayaddison]

@patrickhulce Thanks for the quick response!

For the use case I'm looking at, it fixes an accessibility false-positive (dequelabs/axe-core#1688).

The aria spec considers a combobox having a child with input[type=search] as valid, whereas 3.3.0 marks a failure in that situation. The select2 library renders DOM elements which fall into the failure case.

I hadn't noticed that the size increase was so significant; let me dig around and see if I can figure out what happened there.

[jayaddison]

@patrickhulce It looks like the majority of the bundle size increase is from locale data, much of which is new in 3.4.0. From a slightly unscientific dir-by-dir diff and sort:

cat foo | sort
node_modules/axe-core/axe.d.ts 16K
node_modules/axe-core/axe.d.ts 6K
node_modules/axe-core/axe.js 644K
node_modules/axe-core/axe.js 784K
node_modules/axe-core/axe.min.js 344K
node_modules/axe-core/axe.min.js 404K
...
node_modules/axe-core/CHANGELOG.md 76K
node_modules/axe-core/CHANGELOG.md 88K
...
node_modules/axe-core/doc 584K
node_modules/axe-core/doc 608K
node_modules/axe-core/lib 6.3M
node_modules/axe-core/lib 6.4M
...
node_modules/axe-core/locales 148K
node_modules/axe-core/locales 244K
...

(identical file sizes omitted)

Let me see if the additional locale data would benefit lighthouse; if not, perhaps it can be excluded somehow.

[jayaddison]

@patrickhulce FWIW, another line of possibility is a change in one of axe-core's dependencies:

https://github.com/dequelabs/axe-core/blob/v3.3.0/package.json#L89
vs
https://github.com/dequelabs/axe-core/blob/v3.4.0/package.json#L82
as per dequelabs/axe-core#1707

This seems to result in a good chunk of extra code (basically an inlined import) in the output axe.js.

[jayaddison]

(didn't find anything conclusive on either of those, so some git bisect is happening)

[jayaddison]

Ok, my mistake earlier - in fact it is dequelabs/axe-core#1829 that lead to the marked size increase in axe-core which then resulted in the overall bundle size failures here.

I'm still doing a little more investigation into the precise cause within that PR, and the value of the change to lighthouse, which may take a little more time given that I'm a bit new to each of them.

[jayaddison]

@patrickhulce Alright, yep - I've confirmed locally that it's the introduction of core-js in axe-core (which in turn was necessary for some array functionality polyfilling - cc @straker) that led to the majority of the size increase observed here.

Taking some time out here, but glad to help with any further investigation.

[patrickhulce]

FWIW I don't think 60KB is a dealbreaker, I just want to make sure we're getting something out of this tradeoff. The higher priority issue IMO is the now never-failing audit, really appreciate the investigation though we'd always like to help axe folks out with perf when we can :)

FYI @exterkamp apparently axe has a decent amount of locale data these days we might want to figure out how to leverage in our i18n'ing efforts.

[jayaddison]

@patrickhulce All makes sense, yep. I think incomplete may be a relatively new concept (~late 2017), and implies neither a clear pass nor fail (docs).

IIRC sometimes lighthouse displays grayed out advisory items which need to be checked manually? If it's reasonably possible to transform the multiple-labels check into one of those, that might be an option (I'd probably open it as a PR branching off from here if so).

I didn't find any functional references to the incomplete return code in lighthouse right now, so I assume this would be a new code path if so.

[straker]

@jayaddison Incomplete can also mean the rule threw an error, in which case we report the error in the message of the incomplete result (using the properties error, errorNode, message, and stack).

[jayaddison]

@straker Neat, thanks for the context. Sounds like there's larger scope for comprehensively handling incomplete results, so as a new committer to lighthouse, I might politely bow out of designing & handling those (unless there are any small changes I can help with to improve things).

[patrickhulce]

alright this should be unblocked now with #10072 merging! a simple rebase and we should be good to go

[patrickhulce]

LGTM, thanks so much for sticking with this @jayaddison I know it was a slog! 🎉 💯

[jayaddison]

@patrickhulce Sometimes felt like I've been aiming for a record commit-to-line-diff ratio :)

Just one more yarn type-check issue to resolve which is showing up in master too I think:

lighthouse-core/audits/accessibility/axe-audit.js(51,7): error TS2322: Type 'Result' is not assignable to type 'Product'.

Looking into this currently.

[jayaddison]

I believe #10270 should resolve the type check failures. I'm leaning on CI a little, having run some but not all tests locally.