Babel 6 changes how it exports default

Ecmascript 6CommonjsBabeljs

Ecmascript 6 Problem Overview


Before, babel would add the line module.exports = exports["default"]. It no longer does this. What this means is before I could do:

var foo = require('./foo');
// use foo

Now I have to do this:

var foo = require('./foo').default;
// use foo

Not a huge deal (and I'm guessing this is what it should have been all along). The issue is that I have a lot of code that depended on the way that things used to work (I can convert most of it to ES6 imports, but not all of it). Can anyone give me tips on how to make the old way work without having to go through my project and fix this (or even some instruction on how to write a codemod to do this would be pretty slick).

Thanks!

Example:

Input:

const foo = {}
export default foo

Output with Babel 5

"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
var foo = {};
exports["default"] = foo;
module.exports = exports["default"];

Output with Babel 6 (and es2015 plugin):

"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
var foo = {};
exports["default"] = foo;

Notice that the only difference in the output is the module.exports = exports["default"].


Edit

You may be interested in this blogpost I wrote after solving my specific issue: Misunderstanding ES6 Modules, Upgrading Babel, Tears, and a Solution

Ecmascript 6 Solutions


Solution 1 - Ecmascript 6

If you want CommonJS export behavior, you'll need to use CommonJS directly (or use the plugin in the other answer). This behavior was removed because it caused confusion and lead to invalid ES6 semantics, which some people had relied on e.g.

export default {
  a: 'foo'
};

and then

import {a} from './foo';

which is invalid ES6 but worked because of the CommonJS interoperability behavior you are describing. Unfortunately supporting both cases isn't possible, and allowing people to write invalid ES6 is a worse issue than making you do .default.

The other issue was that it was unexpected for users if they added a named export in the future, for example

export default 4;

then

require('./mod');
// 4

but

export default 4;
export var foo = 5;

then

require('./mod')
// {'default': 4, foo: 5}

Solution 2 - Ecmascript 6

You can also use this plugin to get the old export behavior back.

Solution 3 - Ecmascript 6

For library authors you may be able to work around this problem.

I usually have an entry point, index.js, which is the file I point to from the main field in package.json. It does nothing other than re-export the actual entry point of the lib:

export { default } from "./components/MyComponent";

To workaround the babel issue, I changed this to an import statement and then assign the default to module.exports:

import MyComponent from "./components/MyComponent";
module.exports = MyComponent;

All my other files stay as pure ES6 modules, with no workarounds. So only the entry point needs a change slightly :)

This will work for commonjs requires, and also for ES6 imports because babel doesn't seem to have dropped the reverse interop (commonjs -> es6). Babel injects the following function to patch up commonjs:

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; } 

I've spent hours battling this, so I hope this saves someone else the effort!

Solution 4 - Ecmascript 6

I have had such kind of issue. And this is my solution:

//src/arithmetic.js

export var operations = {
  add: function (a, b) {
      return a + b;
  },

  subtract: function (a, b) {
      return a - b;
  }
};

//src/main.js

import { operations }  from './arithmetic';

let result = operations.add(1, 1);

console.log(result);

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionkentcdoddsView Question on Stackoverflow
Solution 1 - Ecmascript 6loganfsmythView Answer on Stackoverflow
Solution 2 - Ecmascript 6SimenBView Answer on Stackoverflow
Solution 3 - Ecmascript 6WickyNilliamsView Answer on Stackoverflow
Solution 4 - Ecmascript 6Ihor PavlykView Answer on Stackoverflow