ES6 modules: how are circular dependencies supposed to work, as per spec? (webpack vs babel)

I recently upgraded my app to webpack 2. Since webpack 2 now supports ES6 modules, I configured the babel es2015 pre-set with {modules: false} so that the webpack handles imports directly.

My app has circular dependencies that Babel handled just fine, but webpack 2 on its own didn't. I looked at this and found that the code that Babel generates looks essentially like this:

A.js

exports.someFunc = someFunc;
var _b = __webpack_require__(1071);
// ....more imports

      

B.js

var _a = __webpack_require__(256); 

// => _a.someFunc() can now be called immediately as part of the module side effect, i.e. used as a decorator.

      

This works because Babel moves the export destination to A.js at the top.

By dumping the webpack load, the generated code will look like this:

A.js:

var __WEBPACK_IMPORTED_MODULE_7__B__ = __webpack_require__(1071);
exports.someFunc = someFunc;

      

Thus, when module B first starts up, it cannot yet access someFunc

. To be clear, this is fine if someFunc

only used later, but not if it someFunc

is a decorator used during module initialization.

Who is right? Babylon or Webpack?

+3


source to share





All Articles