viewer: add option for loading from the PSI API

[connorjclark]

Split off from #9193

This introduces a way to call PSI from the viewer:

/?url=https://www.example.com&categories=seo,pwa

Had to update puppeteer because the version we had didn't work with request interception on newer Chrome.

[brendankenny]

at a high level:

• (to @paulirish :) we still shouldn't be making a PSI viewer when there's already a PSI viewer (https://developers.google.com/speed/pagespeed/insights/), it just needs to render the other sections and we have web.dev/measure. But w/e, I guess?
• to @connorjclark: can you encapsulate what can be of the PSI stuff similar to the github-api.js file?

[paulirish]

can you add an example localhost:8000?url=... URL in the readme just for convenience

[brendankenny]

viewer code looking good, thanks for sticking with this review process.

Comments mostly on the tests

[brendankenny]

Move into psi-api.js?

[connorjclark]

Defining it in jsdoc:

/**
 * @typedef PSIParams
 * @property {string} url
 * @property {string[]=} category
 * @property {string=} locale
 * @property {string=} strategy
 * @property {string=} utm_source
 */

results in:

[connorjclark]

Refactor that loop (do type checking instead of checking the name of the property)? Or don't do this change? Or some way to define the type in jsdoc and keep the same behavior?

[brendankenny]

oh, ha, that's weird. Somehow the one in d.ts is less strict (setting value to any) than doing it in a typedef (setting value to string | string[] | undefined)

[connorjclark]

done.

[brendankenny]

for these, maybe cleaner to do expect([... interceptedUrl.searchParams.entries()]).toEqual([...])?

[connorjclark]

I think these query params should be tested one at a time.

[brendankenny]

for these, maybe cleaner to do expect([... interceptedUrl.searchParams.entries()]).toEqual([...])?

I think these query params should be tested one at a time.

that's fine, I guess what I was really suggesting is that we should be testing all of them (especially strategy since it gets a default? and probably key, though the exact value matters less) and that form was just a way to cut down on the expect(...).toEqual(...) verboseness

[connorjclark]

OK - done

[brendankenny]

some last nits but otherwise...let's do this
⛵️📎⛳️

[brendankenny]

seems like an elaborate way not to write

expect([...interceptedUrl.searchParams]).toEqual([
  ['url', 'https://www.example.com'],
  ['strategy', 'mobile'],
  // Order in the api call is important to PSI!
  ['category', 'performance'],
  ['category', 'accessibility'],
  ['category', 'seo'],
  ['category', 'best-practices'],
  ['category', 'pwa'],
  ['key', 'AIzaSyAjcDRNN9CX9dCazhqI4lGR7yyQbkd_oYE'],
  // `locale` and `utm_source` aren't set by default.
]);

but either way works :P

[connorjclark]

the array mumbo jumbo doesn't make for very good error message when the assertion fails.