Re-export `Global` from `@emotion/react`

Is your feature request related to a problem? Please describe.

• We need Global from @emotion/react.
• Our monorepo uses eslint-plugin-import/no-extraneous-dependencies to help us ensure we don’t import from any package not defined as a dependency in package.json. Without this, we’ve learned the hard way that Yarn installs and Webpack builds can break without notice.
• This means we should define @emotion/react as a dependency to import Global from it.
• Because Yarn v1 is a broken piece of 💩, yet also the only Yarn version supported by Gatsby Cloud, sometimes this leads to multiple copies of @emotion/react in our dependency tree.
• When this happens, Emotion breaks.

Describe the solution you’d like

Since it’s poor practice to import from a transitive dependency, but unsafe to add @emotion/react as a direct dependency beside theme-ui, I think the right solution is for theme-ui to re-export Global.

<opinions> Users should never be asked to import from any transitive dependency. If we were meant to use @emotion/react directly alongside theme-ui, then @emotion/react would be a peer dependency we would install alongside theme-ui. Since it’s a direct dependency managed by theme-ui, it’s the responsibility of the theme-ui API to re-expose the right parts of it to userland. </opinions>

Describe alternatives you’ve considered

There are probably many alternatives! Futzing around with our ESLint configs, tweaking our dependency models, convincing Emotion not to be so damn fragile, finally selling the Gatsby crew on supporting actual working versions of Yarn… but I really think re-exporting Global is the right move for the project in general.

For now we’re using eslint-disable-next-line import/no-extraneous-dependencies, but the rule exists for a reason 😃

[lachlanjc]

Appreciate the thorough explanation! Makes sense to me, so would totally accept a PR for this.

[aaronadamsCA]

Ha, I just came to close this - agreed it’s no longer relevant!