代码拆分如何与导入/导出以及babel和webpack一起使用？

Question

I am trying to answer,

when to use import/export and when to use require()/module.exports ? But as I try to dig, it seems to get complicated.

Here's my understanding

• require()/module.exports: this is nodejs implementation of the module system. This loads the modules syncronously.
• with es6, we can use import/export. the docs says

The import statement is used to import bindings which are exported by another module. Imported modules are in strict mode whether you declare them as such or not. The import statement cannot be used in embedded scripts unless such script has a type="module".

Ques1 : How does this work with babel or webpack or browsers in general?

As I was exploring I came across stuff like CommonJs, requireJs, Asynchronous Module Definition (AMD)

Ques2 : I am more interested in knowing the timeline as how these things evolved in javascript ?

Answer 1

How does this work with babel or webpack or browsers in general?

Babel and Webpack follow the ES spec and transpile the import / export statement to one single file. As they also support the require syntax, they usually transpile the import statements to require() calls and the export statements to module exports , and then ship with a custom loader for modules., If you got for example:

 // A.js
 export default function() { }

 // B.js
 import A from "./A";
 A();

Then it gets transpiled to the following require syntax:

 //A.js
 exports.default = function() {};

 //B.js
 var A = require("./A").default;
 A();

That could then get wrapped to something like:

 (function() { // prevent leaking to global scope
   // emulated loader:
   var modules = {};

   function require(name) { return modules[name]; }

   function define(name, fn) {
     var module = modules[name] = { exports: {} };
     fn(module, module.exports, require);
   }


  // The code:
  define("A", function(module, exports, require) {
      // A.js
     exports.default = function() { };
  });

  define("B", function(module, exports, require) { 
    // B.js
   var A = require("A").default;
    A();
  });
 })();

how these things evolved in javascript ?

A few years ago, writing JS was restricted to browsers, and the only way to load multiple js sources was to use multiple <script> tags and use the global object to exchange functionality. That was ugly.

Then Nodejs was invented and they needed a better way to work with modules and invented the require() thing.

The writers of the spec saw a need for a native syntax for that, so import / export were introduced.

Babel and others then wrote transpilers.

Answer 2

What webpack the bundler does is the following:

1. You specify an input file in the config
2. You specify an output file the config

Webpack will look at all the files which the input file requires (commomJS module system) or imports (ES6 module system). It then funnels the code based on file name extention through loaders. Loaders can transpile the individual files to code the browser can understand. An example of a loader is babel or the sass/scss compiler.

After the different files are transpiled with loaders, the plugins can work at the transform the bundle of generated code into something else. The bundle is just a bunch of code which together forms piece of functionality

In won't go into detail in the internals of webpack too deeply, but the most important thing to understand is:

You use webpack so you can use split up your code in multiple files, which makes them more maintainable and easier to work with. However then requesting all these files by the client would be horrible for performance (many HTTP requests overhead). Therefore, we bundle the files into one file, or a couple so this overhead is reduced.

Answer 3

Generally, you should write all modern code with import/export syntax if you are using a bundler like webpack, or translating with Babel... npm modules may favor require/module syntax but you can still import them.

Also worth noting is the import() method which returns a promise that should resolve to the root module being imported asynchronously. Webpack may bundle these as asynchronous modules if you have it configured to do so.

In practice the resolution through tooling like babel and webpack will fallback to node-style behaviors against the node_modules lookup, where the standard is transport paths, favoring relative paths. Additional support is per environment.

You can experiment with esm support in modern browsers and in current node (behind a flag as of this answer). The behaviors are somewhat inconsistent, but well defined. When in doubt, experiment and try.