Repository navigation
Duplicate React #675
Description
“Duplicate React” is an incredibly common issue that produces weird errors and confuses beginners and advanced users alike. It happens when you install react but some component you’re using installs its own copy of react (often with a different version).
React doesn’t throw in such cases because there are situations in which multiple React may validly coexist in the page (e.g. a third-party React-powered widget on a React-powered website). However it seems to make much less sense inside a single bundle. Webpack is in a perfect position to do this, but of course it won’t add any library-specific code. The good news is that we’re on top of webpack, so we might be able to do something.
There are several possible options:
-
- Do nothing. (Like now)
-
- Warn/error on duplicate React in the bundle.
-
- Alias React to always be the one on the top level, regardless of Node resolution mechanism.
Option (3) seems like the easiest to do (we can special-case React in our Webpack, and maybe Jest, configs). It also “just works” from the user’s point of view because they don’t need to delete any node_modules or mess with projects’ peerDependencies. The downside is the ecosystem loses because project authors don’t become aware that their components incorrectly depend on React, or that their components are outdated.
Option (2) seems like more work. It’s not immediately clear what message we could provide. Would we tell the user to delete the extra react from the respective node_modules subfolder? Would we tell them to file an issue with that component or library?
Finally, we could stick with doing nothing.
Any thoughts?
Activity
gaearon commentedon Sep 18, 2016
Also I’m not sure if the issue is still going to be that relevant in React 15.4.0 which really puts the renderer code into
react-dom. Maybe not anymore! cc @spicyjsophiebits commentedon Sep 18, 2016
I don't think 15.4 should behave any differently from today though maybe I'm missing exactly how these bad interactions occur.
evocateur commentedon Sep 18, 2016
In my experience, option 3 is the most appropriate for a Webpack-based bundle. Any react-based dependency that doesn't properly express a react peerDependency probably isn't worth depending on in the first place. Another "duplicate react" trigger is using
npm linkwith a dependent that has react as a devDependency (i.e., has a proper peerDependency); option 3 is the only solution for that problem AFAIK.olegafx commentedon Sep 18, 2016
In my projects I'm using alias as a solution of that problem. So my vote is for option 3.
gaearon commentedon Sep 18, 2016
Would anybody like to submit a PR for option 3?
thangngoc89 commentedon Sep 18, 2016
@gaearon I can do it
gaelollivier commentedon Sep 19, 2016
I think this doesn't only apply to React. Already had some troubles with duplicate dependencies in my bundle and I would love the bundler to tell me when that happens / allow me to prevent it. This is especially a problem when using npm link to link multiple private dependencies
proton1k commentedon Jun 9, 2017
Same problem here by using the
react-selectin the npm-link'ed lib module. I see that the issue is still open and there are plenty of helpful explanations (see below), but there's still no final best solution so far ?gaearon commentedon Aug 23, 2017
I think we should just special case
reactandreact-domand issue a hard build error explaining the issue and pointing out which library needs to be fixed (or, if it's a package manager issue, suggest to file it with them).alonbardavid commentedon Oct 10, 2017
Apparently Yarn has a resolutions field that let's you declare what version to use inside
package.json.It also can guide you through the selection process with
yarn install --flat.Works like a charm and it is the right place to handle this kind of issues.
Not sure if NPM has anything of the same.
proton1k commentedon Oct 11, 2017
@alonbardavid in NPM since v3 the flat install is by default, though with some restrictions by "deepness" factor. There is also a dedupe command which may help, but I'm not sure it's the sort of solution for the initial issue.
darrenscerri commentedon Nov 23, 2017
PR #2011 should solve this issue.
penx commentedon Dec 1, 2017
(3) means a developer could have an issue with their dependency tree that is hidden from them. Personally, I'm pleased I got this error as it made me look in to it further, though it took me a long time to find a fix.
I would suggest:
a. there is an environment variable to enable the webpack alias that is by disabled by default
b. warn in the build about duplicate React
c. allow the environment variable to be configured to set other packages to be used as aliases
d. build warnings should mention the env variable
I've read through a lot of Github discussions on peerDependencies and summarised them, along with a description of the
npm linkissue.I had already ejected create-react-app to add source-map-loader to get sourcemaps in a monorepo, and then made a few additional changes to resolve the duplicate React issue.
Allow webpack aliases to be defined in an env variable to prevent dup…
penx commentedon Dec 1, 2017
@gaearon I've made a WIP PR for part (a)+(c) of my suggestion above, part (b) is covered by #2011.
Will finish off the PR if this is desired.
gaearon commentedon Jan 21, 2018
Somewhat relevant: #3883