You are loading @emotion/react when it is already loaded. Running multiple instances may cause problems. This can happen if multiple versions are used, or if multiple builds of the same version are used.

[joeelmahallawy]

Current behavior:
I get this warning: You are loading @emotion/react when it is already loaded. Running multiple instances may cause problems. This can happen if multiple versions are used, or if multiple builds of the same version are used.

I also get a quick flickr where all my styles on the page are messed up when I first load a page, I believe this is from one instance of @emotion/react loading, then another instance loading and overwriting the styles of the previous instance.

To reproduce:

1. Create a Next.js project: npx create-next-app --example with-typescript reproduction
2. Create a _app.tsx file in your /pages folder and add:

import { ChakraProvider, theme } from "@chakra-ui/react";
import { NotificationsProvider } from "@mantine/notifications";
import { AppProps } from "next/app";
import Head from "next/head";
import { MantineProvider, ColorSchemeProvider } from "@mantine/core";
import React, { createContext, useMemo, useState } from "react";

export default function App(props: AppProps) {
  const { Component, pageProps } = props;
  const [colorScheme, setColorScheme] = useState<"light" | "dark">("light");
  const toggleColorScheme = (value?) =>
    setColorScheme(value || (colorScheme === "dark" ? "light" : "dark"));

  return (
    <>
      <ChakraProvider theme={{ ...theme }}>
        <ColorSchemeProvider
          colorScheme={colorScheme}
          toggleColorScheme={toggleColorScheme}
        >
          <MantineProvider
            withGlobalStyles
            withNormalizeCSS
            theme={{
              colorScheme,
              breakpoints: {
                xxxl: 1900,
              },
            }}
          >
            <NotificationsProvider position="bottom-center">
              <Component {...pageProps} />
            </NotificationsProvider>
          </MantineProvider>
        </ColorSchemeProvider>
      </ChakraProvider>
    </>
  );
}

3. Go to http://localhost:3000 and check console for warning

I'm aware the code example above mixes component libraries (which is usually bad practice and a big no no), but what if I want to use a React component from a library that uses @emotion/react? I would get the same issue since Chakra UI uses @emotion/react too and they would overwrite each other. How do I fix this? Is there a way to use several instances and choose which instance overwrites the other? Is it possibly to also have the styles (that don't overwrite) unionize with the other instance's styles? I know I have a lot of questions, but I'm looking for a workaround for this issue without having to choose a different library that doesn't use @emotion/react, someone please help, thanks so much.

Expected behavior:
Normal loading with no CSS flickr and no warning

Environment information:

• react version: 17.0.2
• @emotion/react version: ^11.9.3

[srmagura]

Are there multiple copies of @emotion/react in your node_modules? yarn why or npm ls can help with this.

[Rakesh-99]

I get the same error while using React with Material UI. In text filed while entering values the input filed loses focus after typing a char.

[joeelmahallawy]

I tried yarn why @emotion/react and this was my logs:

[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "@emotion/react@11.9.3"
info Has been hoisted to "@emotion/react"
info Reasons this module exists
   - Specified in "dependencies"
   - Hoisted from "react-admin#@emotion#react"
info Disk size without dependencies: "1.12MB"
info Disk size with unique dependencies: "3.48MB"
info Disk size with transitive dependencies: "10.27MB"
info Number of shared dependencies: 41
=> Found "react-select#@emotion/react@11.9.0"
info This module exists because "react-select" depends on it.
info Disk size without dependencies: "784KB"
info Disk size with unique dependencies: "3.13MB"
info Disk size with transitive dependencies: "9.92MB"
info Number of shared dependencies: 41
=> Found "@mantine/ssr#@emotion/react@11.7.1"
info This module exists because "@mantine#next#@mantine#ssr" depends on it.
info Disk size without dependencies: "2.1MB"
info Disk size with unique dependencies: "3.46MB"
info Disk size with transitive dependencies: "5.06MB"
info Number of shared dependencies: 14
=> Found "@mantine/styles#@emotion/react@11.7.1"
info This module exists because "@mantine#core#@mantine#styles" depends on it.
info Disk size without dependencies: "2.1MB"
info Disk size with unique dependencies: "3.46MB"
info Disk size with transitive dependencies: "5.06MB"
info Number of shared dependencies: 14
✨  Done in 4.97s.```

[srmagura]

Notice how there are multiple versions. There needs to only be one. You can usually resolve this by deleting your yarn.lock and reinstalling, though be aware that this will update all dependencies to the latest version allowed by your package.json.

[joeelmahallawy]

What if the libraries independently use a different version of @emotion/react? So for example if react-select uses version 11.9.2 and @mantine uses version ^11.9.3?

[srmagura]

Hmm, well that situation is best to avoid but if it did happen, it might still be OK... not sure.

[Andarist]

Yes, this should be avoided in the same way as a library should never mandate what exact version of React has to be used by the "host" application. This is exactly a perfect example of a good peer dependency usage - libraries only specify a version with which they work OK but the peer dependency in question is meant to be supplied by the app developer.

[Andarist]

The real problem is in the react-select package - they shouldn't specify Emotion as a regular dependency, it should be a peer.

To workaround this problem I recommend removing Emotion-related entries from your yarn.lock and rerunning yarn to regenerate the lockfile. After such an operation you should end up with a single copy of Emotion.

[joeelmahallawy]

I also don't have a single copy of @emotion/react in my node_modules, instead I only have @emotion

[Andarist]

You most certainly have node_modules/@emotion/react there (package managers group scoped packages in a single directory within node_modules).

[silverwind]

I'm also seeing this silly warning while running vitest. npm ls @emotion/react shows:

├── @emotion/react@11.10.4
└─┬ react-select@5.4.0
  └── @emotion/react@11.10.4 deduped

I would suggest to just remove the warning. Users are not in control of indirect dependencies and suggesting to modifying lockfiles directly is also not really something anyone should ever do.

[Aleff13]

I have the same trouble here, do you know any bypass to this?

[silverwind]

I worked around by using @emotion/css instead of @emotion/react which will also get rid of the Babel dependency.

[MazanLabeeb]

Anyone came up with solution other than deleting package-lock.json/yarn-lock.json file?

[mateusmento]

I had the same warning before but didn't find more than one version of @emotion/react in my node_modules folder.

PS C:\workspace\react-webpack-babel-emotion> npm ls @emotion/react                 
react-webpack-babel-emotion@1.0.0 C:\workspace\react-webpack-babel-emotion
└── @emotion/react@11.10.5

I was able to disable the warning when I included the @emotion/babel-plugin in my .babelrc file.

.babelrc

{
	...
	"plugins": [
		...
		"@emotion/babel-plugin"
	]
}

[JK369x]

help me pls T^T

[Codex-]

If you are stumbling upon this thread in hope of finding an answer as to why you're seeing this, despite only having one version (even deduped) with npm ls:

I found that this was being emitted because we had an app with vite running esm, loading via esm, then a package we were using was using cjs, which then loaded emotion again via the cjs bundle, thus emitting this warning.

Fixing the package exports and generated sources to have both esm and cjs resolved this warning 🚀

[atrauzzi]

@salehkaddoura-alation -- What changes did you make to your vite config?

[salehkaddoura-alation]

@atrauzzi in the rollupOptions config under build I added this

rollupOptions: {
    // External packages that should not be bundled into your library.
    external: [
      'react',
      'react-dom',
      'react/jsx-runtime',
      '@emotion/react',
      '@emotion/styled',
      '@mui/material',
      '@mui/styled-engine-sc',
    ],
  },

[atrauzzi]

Ah great, thanks. How do you tell vite to reference the other library project? Do you build that library using vite?

[salehkaddoura-alation]

yes, the library is built using vite we are also using nx monorepo

[Calfur]

Thanks, adding @emotion/react to the vite.config.ts in the external section was the thing which finally helped me 😃

[ribrown-bishs]

I am seeing this when running a micro frontend setup, using webpack federated modules.
Is there a recommended way to set up @emotion/react (from @mui/material) in a MFE setup?
(I also have troubles sharing the theme across the MFE boundaries)

[eBitzu]

peerDependencies?

[aristocrat44]

I too am getting this warning with my micro frontend that uses vite (which has emotion/react listed in peer and dev dependencies) as components package and NextJs 12 (emotion/react as dependencies) as main.

[hnhegde]

Hello folks, I am seeing the same issue. But my versions are all the same. Can anyone throw some insights?

$ npm ls @emotion/react
square-deal-ui@0.7.0 /home/hnhegde/work/square-deal-ui
+-- @emotion/react@11.10.6
+-- @emotion/styled@11.10.6
| `-- @emotion/react@11.10.6 deduped
+-- @mui/material@5.11.13
| +-- @emotion/react@11.10.6 deduped
| `-- @mui/system@5.11.13
|   +-- @emotion/react@11.10.6 deduped
|   `-- @mui/styled-engine@5.11.11
|     `-- @emotion/react@11.10.6 deduped
+-- react-google-places-autocomplete@3.4.0
| `-- react-select@4.3.1
|   `-- @emotion/react@11.10.6 deduped
+-- react-select-material-ui@8.0.1
| +-- @mui/material@5.0.4
| | `-- @emotion/react@11.10.6 deduped
| `-- react-select@4.3.1
|   `-- @emotion/react@11.10.6 deduped
`-- react-select@5.7.0
  `-- @emotion/react@11.10.6 deduped

$ 

[Codex-]

I just added a log to the sources for both the esm and cjs version to see if it was both of them loading, probably the same thing here

[dbashford]

I am also running into this issue. Any ideas?

[hlopez130300]

Any updated on this? I'm facing the same issue

[Rdlenke]

If you're receiving this message and don't have multiple versions of emotion installed, it might be because both CJS and ESM versions are loading, like @Codex- said above. This is easily verifiable by going to /node_modules/@emotion/{package}/dist/ and doing a simple console.log in each version (if you're building for browsers, these are emotion-react.browser.cjs.js and emotion-react.browser.esm.js. You will see both logs.

If this is your case, you are using webpack, and you have access to webpack.config.js, you can make use of the resolve.mainFields option, to force webpack to prioritize one kind of entry instead of another, like:

module.exports = {
  resolve: {
    mainFields: ['main', 'module'],
  },
};

For emotion, this means prioritizing the cjs version instead of the esm version, as defined in it's package.json:

{
  "name": "@emotion/react",
  "version": "11.4.0",
  "main": "dist/emotion-react.cjs.js",
  "module": "dist/emotion-react.esm.js",
  ...
}

I think you might want to change up the order to [module, main] depending on how your dependencies work, but using [main, module] worked fine here. Also, make sure to delete caches (rm -r ./node_modules/.cache) before running.

Keep in mind that this configuration will be applied to all packages. I'm not sure if you can do it in a non-global way.

@dbashford @salehkaddoura-alation, this might interest you. I'm unsure if the vite option works in the same way, but it might have something similar.

[Andarist]

Note that our explicit goal is for Emotion to load once - despite the CJS & ESM interop quirks. If you could share a runnable repro case that would showcase both CJS and ESM versions being loaded at the same time, I would love to investigate it.

[salehkaddoura-alation]

I was able to resolve the issue, here is a detailed explanation of our use case and how I fixed it for anyone who might need it in the future.

Our use case is that we have multiple Material UI themes that we export as libraries and are bundled using Vite. Vite was bundling @emotion/react and @material-ui packages into the theme lib because they are dependencies. This lib that was bundled using Vite was being used in an older app/project bundled and built using webpack. I believe this was causing multiple instances of emotion and @Material to get loaded which was causing the warning message and the theme styles to not be applied to our components. The solution was to exclude all emotion and material packages from our theme libs and that resolved the issue.

[DrkCoater]

It happened to me today. I'm have Vite + react + emotion/styles,react in pnpm workspace monorepo setup. This is what worked:

1. Change vite config
   export default defineConfig({
   ...
   optimizeDeps: {
   include: ['@emotion/react'],
   },
   resolve: {
   dedupe: ['@emotion/react']
   }
   ...
   });

2. put @emotion/react into 'peerDependencies' in all my package.json

3. Installed @emotion/react under pnpm workspace root
   pnpm i @emotion/react --save --workspace-root

Pretty sure 2 + 3 got rid of the warning for me.

[digital-flowers]

an easy way for CRA just add this to your package.json:

 "resolutions": {
    "@emotion/react": "11.11.0",
    "@emotion/styled": "11.11.0"
  }

this will force all submodules to use this specific version.

[cruessler]

In my project, I was able to fix the warning by setting globals: true in vitest.config.ts. The code that prints the warning message has, among other things, const isTestEnv = typeof jest !== 'undefined' || typeof vi !== 'undefined' which doesn’t have any effect if vi is not available as a global.

emotion/packages/react/src/index.js

Line 20 in 1c60314

const isTestEnv = typeof jest !== 'undefined' || typeof vi !== 'undefined'

[ewanmellor]

Thanks to the answers above for helping me debug this. In my case I only have one copy of Emotion in my package-lock.json and it only showed up with one entry in npm ls so that was not helpful. Here's what I did:

In my src/index.html, added:

    <script>
    window.__EMOTION_REACT_11__ = true;
    </script>

This fools Emotion into thinking that it's already loaded, so you get a console warning from the first version of Emotion to load too. This makes it very easy to place breakpoints where the warning is emitted. Reload the page, and you can see the backtrace for how Emotion is getting loaded.

In my case, it was react-google-places-autocomplete > react-select which includes Emotion as a dependency. There is already an issue open on react-select for this. I'm sure it would help if an Emotion maintainer added a comment there too. JedWatson/react-select#5658

[ewanmellor]

/cc @Andarist

[nichita-pasecinic]

ViteJS config that fixes the error:

resolve: {
  dedupe: ['@emotion/react']
}

[materazu]

omg, you save me.
Thanks a lot for that @nichita-pasecinic!

[Codex-]

worth noting that while this helps mitigate duplicated packaging of emotion, it doesn't resolve the duplicate in your resolved modules.

npm ls @emotion/react to track down what is pulling what (peers vs hard deps) and using package overrides would lead to a cleaner lock and singular resolution for the package.

[materazu]

Obviously, but it always depends on the context.
In this case being in monorepo nx and on a somewhat complex step-by-step migration on a large project (I can't remove everything at once), this solution solved my problem.