What is this?

With #447, the new static.rewrites config file option was added to a config module constant that determines which object properties are normalized and which aren't. Before that PR, the constant was initially created to prevent normalizing discovery.request-headers options, and subsequently later discovery.cookies options.

This was all easy to do as the changes came up since the aforementioned options were defined by other packages within this repo. However, outside of this repo where config schemas can still be defined, there is no such mechanism for disabling normalization of a property. In order to do so, a dedicated PR must be opened on this repo to add the desired properties to the constant.

Instead, with this PR, normalization can be disabled for a property by its own schema. The PercyConfig.normalize method now accepts another option which can define a schema to normalize against. In order to get a property's associated schema, the getSchema validation helper was updated to accept a path. Upon providing a path, the function will now return an array of schema's indexed by each part of the path, with the zero indexed item being the root schema.

If a path is provided, subsequent nested schemas will be accumulated with the original root schema by recursively fetching the next path's schema. To facilitate schema references, the base functionality of this method will now resolve any $ref in a provided schema by once again recursively fetching the desired schema and plucking out the referenced meta path. For schemas that actually contain more than a single possible schema, such as tuples or meta schemas like oneOf, the best matching schema is determined by how deep the paths match; with a bias towards loosely matched schemas that can contain properties not defined by said schema.

After the extensive getSchema and minor normalize changes, the migrate helper was also updated to accept a schema to migrate against (defaulting to the default config schema). Since normalization can be dependent on a schema, and because migrations normalize their data, the migrate helpers were updated to allow defining migrations for specific schemas. While this won't be utilized immediately for migrating other options, it can definitely come in handy for future deprecations or breaking changes.

In addition to the changes described above, the test that was added also uncovered a merge bug that was fixed by re-contextualizing the merge if the merge path is mapped to another path. Before, when mapping parent keys of arrays, the context was lost which could trick the following logic into thinking it was creating a new array rather than concatenating arrays. An extra normalization usage in the load method was also removed because empty values as a result of pruning invalid options are already removed by validation changes in #406.

Because of the changes in this PR, and in addition to those validation changes, other small codepaths were (re)moved. There was an old codepath for duplicate "using config" logs that was handled in the core constructor. With the new changes, we can move this to within the load method itself. If a file is not loaded, the log will not happen; but validation will still be performed in addition to merging with defaults as the old code path did. This actually improves core config options by always validating, even when not loaded by a file. Another code path, which normalized snapshot options, was moved into the snapshot options config helper introduced in #416.

Me adding new config options to the Storybook SDK: https://www.youtube.com/watch?v=AbSehcT19u0