Would appreciate feedback on how to fix this typecheck issue 😓
Error info can be found in this run.

Hm, so this typecheck issue is technically correct since the fields of the ICustomThemeConfig type have type string | BaseTheme | null, and we need a string here.

I'm not sure why this wasn't caught by typescript earlier, but this probably happened because some dependency wasn't typed (or typed less strictly) so checks related to it were skipped, and types were added in a minor version upgrade so now types are being more strictly enforced in more places.

Two things need to be done to fix this:

1. Unpack the base field of themeInput (and probably name it _base to signify that it's unused) on line 371 above so that customColors doesn't include it. base isn't a color so shouldn't be included in parsedColors, but we must have missed this when it got added because of the lax typechecking for this code (I don't think it mattered that it was being included, but we should probably fix this anyway for good practice's sake).
2. Somehow cast color to a string before it's used. I think the best way of doing this would probably be to cast customColors as a Record<string, string> before it's used in line 375 rather than casting color itself. We know that every value in customColors should be a string because completeThemeInput is always called before createEmotionTheme in the createTheme function (and also because we got rid of the font/base fields, which are the only two non-string fields), but the type checker isn't smart enough to infer this.

Hm, so this typecheck issue is technically correct since the fields of the ICustomThemeConfig type have type string | BaseTheme | null, and we need a string here.

I'm not sure why this wasn't caught by typescript earlier, but this probably happened because some dependency wasn't typed (or typed less strictly) so checks related to it were skipped, and types were added in a minor version upgrade so now types are being more strictly enforced in more places.

Two things need to be done to fix this:

1. Unpack the base field of themeInput (and probably name it _base to signify that it's unused) on line 371 above so that customColors doesn't include it. base isn't a color so shouldn't be included in parsedColors, but we must have missed this when it got added because of the lax typechecking for this code (I don't think it mattered that it was being included, but we should probably fix this anyway for good practice's sake).
2. Somehow cast color to a string before it's used. I think the best way of doing this would probably be to cast customColors as a Record<string, string> before it's used in line 375 rather than casting color itself. We know that every value in customColors should be a string because completeThemeInput is always called before createEmotionTheme in the createTheme function (and also because we got rid of the font/base fields, which are the only two non-string fields), but the type checker isn't smart enough to infer this.