Antes, Babel agregaba la línea module.exports = exports["default"]. Ya no hace esto. Lo que esto significa es antes de que pueda hacer:

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

Ahora tengo que hacer esto:

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

No es un gran problema (y supongo que esto es lo que debería haber sido todo el tiempo). El problema es que tengo mucho código que depende de la forma en que funcionaban las cosas (puedo convertir la mayor parte a importaciones de ES6, pero no todas). ¿Alguien puede darme consejos sobre cómo hacer que la vieja forma funcione sin tener que pasar por mi proyecto y arreglar esto (o incluso alguna instrucción sobre cómo escribir un codemod para hacer esto sería bastante ingenioso).

¡Gracias!

Ejemplo:

Entrada:

const foo = {}
export default foo

Salida con Babel 5

"use strict";

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

Salida con Babel 6 (y el complemento es2015):

"use strict";

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

Tenga en cuenta que la única diferencia en la salida es el module.exports = exports["default"].

Editar

Puede que le interese esta publicación de blog que escribí después de resolver mi problema específico: malentendidos módulos ES6, actualización de Babel, lágrimas y una solución

También puede usar este complemento para recuperar el exportcomportamiento anterior.

Si desea un comportamiento de exportación de CommonJS, deberá usar CommonJS directamente (o usar el complemento en la otra respuesta). Este comportamiento se eliminó porque causó confusión y condujo a una semántica ES6 no válida, en la que algunas personas habían confiado, por ejemplo

export default {
  a: 'foo'
};

y entonces

import {a} from './foo';

que es ES6 no válido pero funcionó debido al comportamiento de interoperabilidad de CommonJS que está describiendo. Desafortunadamente, no es posible admitir ambos casos, y permitir que las personas escriban ES6 no válidas es un problema peor que obligarlo a hacerlo.default .

El otro problema era que era inesperado para los usuarios si agregaban una exportación con nombre en el futuro, por ejemplo

export default 4;

luego

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

pero

export default 4;
export var foo = 5;

luego

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

Para los autores de la biblioteca, puede solucionar este problema.

Por lo general, tengo un punto de entrada index.js, que es el archivo al que apunto desde el campo principal package.json. No hace nada más que reexportar el punto de entrada real de la lib:

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

Para solucionar el problema de babel, cambié esto a una importdeclaración y luego asigné el valor predeterminado a module.exports:

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

Todos mis otros archivos permanecen como módulos ES6 puros, sin soluciones. Entonces, solo el punto de entrada necesita un cambio ligeramente :)

Esto funcionará para los requisitos de commonjs, y también para las importaciones de ES6 porque babel no parece haber eliminado la interoperabilidad inversa (commonjs -> es6). Babel inyecta la siguiente función para parchear commonjs:

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

¡He pasado horas luchando contra esto, así que espero que esto le ahorre el esfuerzo a otra persona!

He tenido ese tipo de problema. Y esta es mi solución:

//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);