fix(theming): allow theming of typescript consumers

[austingreendev]

⚠️ This PR includes a rename to an existing export. Normally this would be a breaking change, but I'm categorizing this as a fix as the original export wasn't providing any information. ⚠️

Description

This PR modifies how we provide and consume our GardenTheme interface within react-theming. These changes will make it possible for other codebases to more easily consume our theme within TypeScript codebases.

Detail

styled-components requires consumers to define their own DefaultTheme within their codebase. We've accomplished this in our react-components and website repositories.

Up to this point we have been exporting the DefaultTheme object from styled-components within the react-theming package. Due to the ponyfill approach above this has actually been exporting an empty ({}) interface this whole time 🤦

Approach

The new approach is to define a separate IGardenTheme interface that defines the expected structure of the Garden theme. This new interface is only used in the ThemeProvider component. All other usages and utilities still consume the DefaultTheme from styled-components to allow consumers the flexibility to customize the theme structure.

For consuming codebases this would be the format to type their theme:

import 'styled-components';
import { IGardenTheme } from '@zendeskgarden/react-theming';

declare module 'styled-components' {
  export interface DefaultTheme extends IGardenTheme {}
}

Checklist

• 👌 design updates are Garden Designer approved (add the
  designer as a reviewer)
• 🌐 demo is up-to-date (yarn start)
• ⬅️ renders as expected with reversed (RTL) direction
• 🤘 renders as expected with Bedrock CSS (?bedrock)
• ♿ analyzed via axe and evaluated using VoiceOver
• 💂‍♂️ includes new unit tests
• 📝 tested in Chrome, Firefox, Safari, Edge, and IE11

[louisscruz]

I think another way around this without using any is...

const { ...palette, product } = PALETTE;

[austingreendev]

Since PALETTE is inferring its type this can cause a bunch of Index signature is missing in type errors. The original ... operator is what keeps this working.

We probably shouldn't be inferring those types anyway, but that is probably a larger scope change than we should do here.

[jzempel]

nice.