feat(stack-packs): added draft for stack packs

[wardpeet]

Summary
This is a draft of stack packs to show how the integration will look like and to discuss some pain points before we actually implement it.

I've added a stack-packs.js file inside lib that creates the lhr result for stackpacks. It detects these stack-packs from LH artifacts.

The draft design of the stack pack result looks like:

export interface StackPacks {
  id: string;
  icon: string;
  detectedLibraries: string[];
  advice: Record<string, string>;
}

this would map to

{
  "id": "WordPress",
  "icon": "data:image/...",
  "detectedLibraries": ["WordPress"],
  "advice": {
    "unused-css-rules": "Consider reducing, or switching, ...",
    "uses-webp-images": "Consider using a plugin/service...",
  }
}

---

note, this ended up as

interface StackPack {
  /** The unique string ID for this stack pack. */
  id: string;
  /** The title of the stack pack, to be displayed in the report. */
  title: string;
  /** A base64 data url to be used as the stack pack's icon. */
  iconDataURL: string;
  /** A set of descriptions for some of Lighthouse's audits, keyed by the audits' `id`. */
  descriptions: Record<string, string>;
}

---

A put up a small demo up:
http://wardpeet-filestorage.surge.sh/lh-store/pr-7243/report.html

Related Issues/PRs
#7021

[patrickhulce]

Nice!

[paulirish]

talked this out with @patrickhulce ... Here's the proposal:

1. We plan now for detections that won't be possible with js-lib-detector.
2. We rename our JSLibraries artifact to Technologies, and we could add more items to the array based on our own evaluation of the networkRecords, etc. (Like for stack packs for Fastly, Cloudflare, etc)
3. We retitle the current 'js-libraries' audit because it'll now include things beyond just js-libraries.
4. We use the definitions below.

stack pack definition:

stackPacks: [
  { 
      id: 'wordpress'
      title: 'WordPress',
      iconDataUri: 'data:image/...',
      requiredTechnologies: ['js:wordpressapi', 'core:wordpress'], // see 'type' and 'id' below.
      advice: {
        'unused-css-rules': 'Consider reducing, or switching, the number of [WordPress plugins](https://wordpress.org/plugins/) loading unused CSS in your page. To identify plugins that are adding extraneous CSS, ........',
        'uses-webp-images': 'Consider using a plugin/service that will automatically convert your uploaded images to the optimal formats.',
        // ...
      }
  }
}

Technologies artifact

interface GathererArtifacts {
  // ...
  Technologies: DetectedTechnology[]
}

interface DetectedTechnology {
  type: 'js', // basically the source of the detection. js is js-library-detector.. 
              // and 'core' is any detections custom defined in lighthouse's Technologies artifact.
  id: string //  if (type=='js') lib.npmPkgName || lib.icon. 
             //  if (type=='core') whatever we think is decent.
  name: string // the display-friendly name of the technology
  version?: string // any version data we have
  npm?: string // npmPkgName if it exists
}

[wardpeet]

sounds good to me, let me cleanup this PR to get comments resolved

[brendankenny]

We rename our JSLibraries artifact to Technologies

Unless we're renaming these "TechPecks", it seems like it's confusing to call this anything but Stacks? "Stack" is already super overloaded, referring both to entire stacks and also parts of the entire stack.

iconDataUri

we just say URL now :)

[brendankenny]

interface DetectedTechnology {
  type: 'js', // basically the source of the detection. js is js-library-detector.. 
              // and 'core' is any detections custom defined in lighthouse's Technologies artifact.

What is type communicating? If it's the type of stack, it seems like core needs to instead be more about the stack and not how it was detected. If it's how it was detected, it doesn't seem that important to have, but for debugging and whatever, maybe a different property name? (e.g. detector: 'js-library-detector', detector: 'core', etc)

[patrickhulce]

If it's how it was detected, it doesn't seem that important to have, but for debugging and whatever, maybe a different property name? (e.g. detector: 'js-library-detector', detector: 'core', etc)

Yeah it's changed to now be how it is detected, so +1 to renaming to detector or something 👍

[paulirish]

it seems like it's confusing to call this anything but Stacks?

K. That works for me. requiredStack: ['...', '...']

What is type communicating?

another +1 for type -> detector.

[housseindjirdeh]

FYI : Submitted a pull request to include WordPress detection to the library-detector (since we still plan to use it for V1)

[exterkamp]

I think my blocking comments have been addressed, i.e. proto.

[brendankenny]

I have some more clean-up ideas for some of the comments and the Stack types, but the overall structures look good (and I took too long with my changes :).

I don't want to block #8154, etc, which are necessary for getting i18n going, so let's move forward. I fixed the cli snapshot test and we can merge when green, then proceed from there

[brendankenny]

🎉 🎉

[brendankenny]

just a warning for those using file:./ and yarn, as far as I can tell yarn copies the directory into node_modules/, and then any changes you make to that directory after that aren't reflected when you run things.

I've been deleting the @lighthouse/stack-packs entry from yarn.lock and then running yarn again to force yarn to recopy the directory, but maybe there's an easier way :)

[patrickhulce]

does --check-files help?