Add a warning about using different builds

Before 4.4, you could do this w/out problems:

import MemoryRouter from 'react-router-dom/MemoryRouter';
import { Link } from 'react-router-dom';

<MemoryRouter>
  <Link /> // Error!
</MemoryRouter>

It’s not very obvious, but those two import statements may actually reference different builds. The first one is using our CommonJS build, and the second one may be using the ES modules or the CommonJS build, depending on how your build is setup and where you told it to find files from the react-router-dom package. If you’re using webpack (which you probably are) then it’s probably pulling from the ES modules build.

In the case where <Link> is coming from a different build (or any other component, e.g. <Route>), you will currently run into an error like this:

You should not render a <Link> outside a <Router>

This is because of the context object mismatch, which is a problem introduced by our using the new context API. Basically, each build has its own context object, and components from different builds can’t be used together.

For this reason, I think it’d be nice to provide a better warning for folks who might be pulling the files from different builds accidentally, like I was doing (see 6460fe0862c40b7f726cc3d47d03cc9bbde74ff4). Maybe something like:

You are using two different builds of React Router in the same application. To fix this, please make sure you always import from the same build. [link to a gist or some docs page that explains the issue more thoroughly].

[jimthedev]

Is this also a concern for libraries that import {Link} from "react-router-dom"; and then are imported into an application which has its own router?

More specifically if I have a library of more complex components that contain various <Link> and <NavLinks inside them, how can an application import components from my library and use the correct context (the application router context) even though the code lives in a separate bundle?

[timdorr]

We had originally added the transform-imports function in #5095. The motivation was bundle sizes from duplicate modules, but this has an overlapping concern that’s now exposed as a header.

Regardless of the approach taken, we’ll want to make sure we keep the bundle size in mind. Fixing one will likely fix the other. It’ll be annoying, but I’d suggest setting up a test repo, npm linking in RR and RRD, and checking output sizes as you try various things.

Rollup has got good DCE built-in nowadays and Webpack respects the sideEffects: false key we added to the package.json’s. So, I think it should be easy enough to solve by just following best practices.