core(config): remove dead config format code

[adamraine]

We stopped using this code everywhere in 10.0, but didn't actually remove it because we thought someone out there might still want to dig into our internals if need be. I don't think anyone has asked us about this, so I think it's safe to remove at this point.

[brendankenny]

We stopped using this code everywhere in 10.0, but didn't actually remove it because we thought someone out there might still want to dig into our internals if need be.

To me this is still basic table stakes for a CLI with a config format (another example). I'd like to see it added back as a CLI flag after classic mode is removed and an architecture like #14048 makes it more straightforward for the CLI to use it (without conflating that use with a "public" API).

It's 45 lines of code (including comments) + tests that makes it so you can debug why your extends or onlyAudits is failing without having to set a breakpoint in Lighthouse itself. Seems like an easy tradeoff.

I don't think anyone has asked us about this, so I think it's safe to remove at this point.

The majority of our users aren't CLI users. The vast majority use PSI/DT, and of those who install, many likely just use the node module. It's also a difficult thing to judge, because there could be reluctant upgraders who just haven't filed an issue. For instance, in the last 7 days there were 25% more installs of the last 9 release (9.6.8) than of all the 10.x releases combined. Many of those are probably from set and forget in a package.json somewhere, but at least a few are likely due to breaking changes being too onerous to justify upgrading at the moment.

After the discussion summarized in #14547 (comment), I realized I had done a poor job communicating the hard-won benefits of the config format in spite of its warts because I was apparently the only one who knew about them :)

lighthouse/core/test/config/config-test.js

Lines 510 to 520 in 3d78192

	it('returns a valid config that can make an identical Config', async () => {
	// depends on defaultConfig having a `path` for all gatherers and audits.
	const {resolvedConfig: firstConfig} = await initializeConfig('navigation');
	const firstPrint = getConfigDisplayString(firstConfig);
	const {resolvedConfig: secondConfig} =
	await initializeConfig('navigation', JSON.parse(firstPrint));
	const secondPrint = getConfigDisplayString(secondConfig);
	expect(firstPrint).toEqual(secondPrint);
	});

is a test of a really nice property! And the more invariants like that that are removed, the more the config becomes just a grab bag of whatever we're thinking about that day, and the harder it is to evolve over time without major breaking changes.

[adamraine]

The majority of our users aren't CLI users. The vast majority use PSI/DT, and of those who install, many likely just use the node module. It's also a difficult thing to judge, because there could be reluctant upgraders who just haven't filed an issue. For instance, in the last 7 days there were 25% more installs of the last 9 release (9.6.8) than of all the 10.x releases combined. Many of those are probably from set and forget in a package.json somewhere, but at least a few are likely due to breaking changes being too onerous to justify upgrading at the moment.

I won't die on this hill and this PR may be jumping the gun. That being said, I think there is a lot of refactoring to do before the resolved config is ready to be exposed again as these tests suggest. Probably best to circle back after legacy is removed not before.