Never `import React from ‘react’` again, thanks to Webpack’s ProvidePlugin
JK Eldon
26619

While it may be tempting to eliminate the import statements, here are some drawbacks you should consider before doing this:

  1. It makes your code browser specific. (Removes universality). If you were wanting to run the same bit of code on client and server, then you couldn’t because the server side code wouldn’t necessarily be using webpack. This is a big deal for library authors.
  2. Explicit imports provide a visual way to show coupling and complexity. They take an implicit dependency of the code and make it explicit. This improves clarity by reducing “magic” and leads to fewer runtime bugs.
  3. Linting is harder. If you are using eslint and have it integrated with your editor, it will warn you when you try to use something that hasn’t been imported, or conversely when you are importing something that is no longer being used in this file.
  4. Dead code removal is harder: If for example you are providing a plugin and are only using it in a couple files, then later remove it from those files, you might forget to remove the provide statement (or be too worried that it could break something). Then you’ll be including a library in your final bundle that isn’t actually being used. Conversely if you import explicitly, your linter should warn you when an import is going unused. Then you remove the import and any code that doesn’t get imported, doesn’t end up in the final bundle.

Explicit imports are one of the big reasons we moved away from the rails asset pipeline to a webpack based build. Globally defined and included dependencies ultimately lead to bloat and cases where you don’t know which modules you are actually even using anymore.