Duplicate React

[gaearon]

“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:

• 1. Do nothing. (Like now)
• 2. Warn/error on duplicate React in the bundle.
• 3. 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?

[gaearon]

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 @spicyj

[sophiebits]

I don't think 15.4 should behave any differently from today though maybe I'm missing exactly how these bad interactions occur.

[evocateur]

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 link with 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]

In my projects I'm using alias as a solution of that problem. So my vote is for option 3.

[gaearon]

Would anybody like to submit a PR for option 3?

[thangngoc89]

@gaearon I can do it

[gaelollivier]

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]

Same problem here by using the react-select in 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 ?

• https://github.com/JedWatson/react-select/issues/1704
• https://facebook.github.io/react/warnings/refs-must-have-owner.html
• https://github.com/npm/npm/issues/7742
• https://github.com/webpack/webpack/issues/554#issuecomment-183781042
• https://www.npmjs.com/package/npm-dedupe-symlinks
• http://webpack.github.io/docs/troubleshooting.html#npm-linked-modules-doesn-t-find-their-dependencies

[gaearon]

I think we should just special case react and react-dom and 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]

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]

@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]

PR #2011 should solve this issue.

[penx]

(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 link issue.

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.

[penx]

@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]

Somewhat relevant: https://github.com/facebookincubator/create-react-app/issues/3883