For Library Authors

If you are writing a component library, carefully consider whether your library will depend on Emotion. A simple alternative is to include a regular CSS file in your package, which your users bring in via a normal import statement.

If you're reading this, you probably know about Emotion's many benefits. Here are some drawbacks to consider:

• Consuming applications will have to use the same version of Emotion as the library. There will be issues if, for example, your library depends on Emotion 11 but a user's application depends on Emotion 10.
• If your package only contains a handful of small components, Emotion may significantly increase your package's bundle size.
• Emotion may be more error prone than a simple CSS file in certain edge cases. For example, in a previous version of react-loading-skeleton which utilized Emotion 10, we received reports of styles not working in production builds, iframes, and the shadow DOM.

If you do choose to use Emotion in your library, it is best to list the Emotion packages as peer dependencies in your package.json. This ensures that your library and the consuming application get the same instance of each Emotion package.