Consider refactoring presets config into repo/package

Summary Following a discussion with @brendankenny on configuring Lighthouse, I improved the docs a little recently around using and extending presets with the node module programmatically. (https://github.com/GoogleChrome/lighthouse/pull/7354)

You can currently extend a preset like so:

{
    extends: 'lighthouse:default',
    settings: {
        emulatedFormFactor: 'desktop',
        ...
    },
}

The limitation is that you can only use lighthouse:default or lighthouse:full in this way. I clarified this limitation in the docs after I was unable to extend one of the other presets I found in the lighthouse-core/config directory.

Option 1: We could update the logic to allow you to extend any preset found in the lighthouse-core/config. However, the problem with that is you have to make sure the configs are named in a particular format to be picked up. It’s also not very visible to the user about what presets are available. The fact I went looking in Lighthouse internals is a bit of a red flag here.

The other big issue for me is that we’re basically re-inventing object composition. In JavaScript, we extend objects with Object.assign (or using spread operator), so it seems totally unnecessary to be building our own extends logic here.

So I’m not super keen on this personally.

Option 2:

What if we created a lighthouse-presets repository or at least a package that contains a number of useful preset configs that you can import into your own project? lighthouse-core could also bring it in interally as a dependency so it’s all managed in one place.

At that point, if a user wants to extend any of those presets, they can import one and do an object merge with their own config, rather than relying on the extends property. It seems like a much more natural way to me to do in my opinion.

const lighthouse = require('lighthouse');
const desktopPreset = require('lighthouse-presets/desktop'); 

const myConfig = Object.assign({}, desktopPreset, {
    cpuSlowdownMultiplier: 5
});

await lighthouse(url, opts, myConfig);

I don’t know how many presets we’re likely to have, but with more and more settings being available, there’s a chance we could see a lot more standard variations, and with a separate repository or package, there’s more visibility of what’s available.

Option 3:

We don’t think configs will scale and the current mechanism is good enough, provided we remain clear in the docs. This is still a perfectly valid option.

I’m happy to help around this.

[patrickhulce]

If it’s a string, look up the config as normal (including any in the directory). If the config object is passed in, use that as the base config and continue to merge that and the user’s config internally.

This sounds good to me!

Or just have a shortcut export to the configs directory.

This also works for me. I’m a big fan of export aliases 👍

It seems like there are a few concrete steps then to make this happen:

• Add support for recursively extending configs. (Fairly difficult and complicated)
• Add support for extends to use any preset, not just lighthouse:default/lighthouse:full. (Relatively easy)
• Add support for accepting an object as the extends property. (Relatively easy)
• Add folder for aliasing and exporting the presets. (Relatively easy)

The recursive extension is definitely the hardest step in here. What are we going to do when multiple configs have onlyAudits for example, concat them or override? Lots to think through here for each property that we didn’t have to worry about when it’s just full configs that are being extended.

This step in particular seems like work that would require a decent amount of care in implementing, so I think it makes sense to validate this need is broad enough to prioritize before getting started.

Open call for +1s if you’ve needed this functionality before repo watchers 😃

[connorjclark]

We’re open to making the config more extensible, but probably not gonna put these files in a separate repo. (extends implies more than is possible atm). May come back to this in the future.