Babel 6 cambia cómo exporta el valor predeterminado

Antes, babel agregaría la línea module.exports = exports["default"] . Ya no hace esto. Lo que esto significa es antes de que pudiera 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 un montón de código que depende de la forma en que las cosas solían funcionar (puedo convertir la mayor parte a las importaciones de ES6, pero no todo). ¿Alguien puede darme consejos sobre cómo hacer que el trabajo antiguo funcione sin tener que pasar por mi proyecto y arreglarlo? (O incluso algunas instrucciones sobre cómo escribir una aplicación para hacer esto sería bastante hábil).

¡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 el resultado es module.exports = exports["default"] .


Editar

Puede que le interese este blogpost que escribí después de resolver mi problema específico: malentender módulos ES6, actualizar Babel, Tears y una solución

También puede usar este complemento para recuperar el antiguo comportamiento de export .

Si desea el comportamiento de exportación de CommonJS, necesitará usar CommonJS directamente (o usar el complemento en la otra respuesta). Se eliminó este comportamiento porque causaba confusión y daba lugar a una semántica inválida de ES6, en la que algunas personas habían confiado, por ejemplo

 export default { a: 'foo' }; 

y entonces

 import {a} from './foo'; 

que no es válido ES6 pero funcionó debido al comportamiento de interoperabilidad de CommonJS que está describiendo. Lamentablemente, no es posible admitir ambos casos, y permitir que las personas escriban ES6 no válido es un problema peor que hacerlo por .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; 

entonces

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

pero

 export default 4; export var foo = 5; 

entonces

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

Para los autores de la biblioteca, es posible que pueda solucionar este problema.

Normalmente tengo un punto de entrada, index.js , que es el archivo que señalo desde el campo principal en 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 statement de import y luego asigno el valor predeterminado a module.exports :

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

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

Esto funcionará para las necesidades de Commonjs, y también para las importaciones de ES6 porque babel no parece haber abandonado la interoperación inversa (commonjs -> es6). Babel inyecta la siguiente función para remendar 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 alguien más!

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