core: internalize normalized configs

[adamraine]

#14048

No longer exposing generateConfig and generateLegacyConfig on the surface api.

Some renames to make this more clear

• Config -> LegacyNormalizedConfig
• FRConfig -> NormalizedConfig

[adamraine]

Drive-by: we don't want users to know about this

[brendankenny]

It might be worth discussing the goals with generateConfig and generateLegacyConfig in the next sync. One key point is that configs aren't internal structures, they're just the normalized version of an input "config json" with all the optional properties filled in. Configs are required to be valid config jsons that normalize to themselves.

generateConfig doesn't expose anything that should be shielded from the user because it just returns a config, which users can already make themselves, and any breaking change to that format would be a public-facing breaking change anyways (navigations is the ugly spot on that, but that's why we already plan to include it in the 11.0 clean-up breaking changes).

If the reason to get rid of them isn't for hiding internals but just for keeping the API simple (why would a user need to call this?), I can see that but it also seems like it might be better postponed for the separation of the core interface from the node interface in #14048. It might not make sense for node users to call generateConfig (though is #14048 (comment) resolved?), but in terms of architecture layering, cli/bin.js should ideally only interact with the public core/index.js API, not reach inside. The client entry points have also drifted from only interacting with core/index.js as they did at one point, but as #14048 progresses hopefully we can get back there.

[brendankenny]

re config naming:

input-config format vs normalized-config format is the same divide that the Config.Json vs Config names were added to differentiate. At the time we recognized that it wasn't all that self explanatory (notably the config json can actually be js :), but almost all cases where code touches a config (or part of a config) it's actually a normalized config, so we preferred to give that one the short and sweet name Config. We completely failed on coming up with a compelling name for the pre-normalization format, but at least it was just a little code in cli/ and config.js that had to live with configJson/Config.Json.

That decision still seems ok. NormalizedConfig is a mouthful when capital-C Config conveys the same thing. If we're primarily concerned with differentiating the public API, revisiting the "config json" bikeshed seems like it could yield a bigger improvement.

[adamraine]

generateConfig doesn't expose anything that should be shielded from the user because it just returns a config, which users can already make themselves, and any breaking change to that format would be a public-facing breaking change anyways (navigations is the ugly spot on that, but that's why we already plan to include it in the 11.0 clean-up breaking changes).

navigations is indeed the ugly spot that motivated this. With the new FR config as default, anyone already using generateConfig will find themselves working with this weird internal property on an otherwise normalized object. Perhaps we could throw a delete navigations in the generateConfig to prevent that 🤷

though is #14048 (comment) resolved?

Yeah, sound like they were using generateConfig because of a bug with skipAudits and onlyAudits together. Is this correct @paulirish @benschwarz?

That decision still seems ok. NormalizedConfig is a mouthful when capital-C Config conveys the same thing. If we're primarily concerned with differentiating the public API, revisiting the "config json" bikeshed seems like it could yield a bigger improvement.

I prefer the more specific name on our internal stuff. If we are moving to publicly exposed types, it would be better to have the Config type reserved for the config objects users will be interacting with. That's putting the cart before the horse though so I won't die on this hill.

[adamraine]

Discussed with @paulirish and @brendankenny. Path forward looks like:

• Remove the generateConfig functions
• Remove the --print-config CLI flag
• Config.FRConfig -> ResolvedConfig and make all variables of this type resolvedConfig
• Config.Config -> LegacyResolvedConfig and make all variables of this type resolvedConfig
• Config.Json -> Config and make all variables of this type config

[adamraine]

Closing and splitting this up