O Babel 6 altera como exporta o padrão

Antes, o babel adicionava a linha module.exports = exports["default"] . Não faz mais isso. O que isto significa é antes que eu pudesse fazer:

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

Agora tenho que fazer isso:

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

Não é um grande negócio (e eu estou supondo que isto é o que deveria ter sido o tempo todo). A questão é que eu tenho um monte de código que dependia da maneira como as coisas funcionavam (eu posso converter a maior parte para importações ES6, mas não todas). Alguém pode me dar dicas sobre como fazer o jeito antigo de trabalhar sem ter que passar pelo meu projeto e consertar isso (ou até mesmo algumas instruções sobre como escrever um codemod para fazer isso seria bem legal).

Obrigado!

Exemplo:

Entrada:

 const foo = {} export default foo 

Saída com Babel 5

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

Saída com o Babel 6 (e o plugin es2015):

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

Observe que a única diferença na saída é o module.exports = exports["default"] .


Editar

Você pode estar interessado nesta postagem do blog que escrevi depois de resolver meu problema específico: Entendendo mal os módulos do ES6, Atualizando o Babel, Lágrimas e uma solução

Você também pode usar esse plug – in para recuperar o antigo comportamento de export .

Se você quiser o comportamento de exportação do CommonJS, você precisará usar o CommonJS diretamente (ou usar o plugin na outra resposta). Esse comportamento foi removido porque causou confusão e levou à semântica ES6 inválida, na qual algumas pessoas confiaram, por exemplo.

 export default { a: 'foo' }; 

e depois

 import {a} from './foo'; 

que é ES6 inválido, mas funcionou devido ao comportamento de interoperabilidade do CommonJS que você está descrevendo. Infelizmente, o suporte a ambos os casos não é possível, e permitir que as pessoas escrevam ES6 inválido é um problema pior do que fazer você .default .

A outra questão era que era inesperado para os usuários se eles adicionassem uma exportação nomeada no futuro, por exemplo

 export default 4; 

então

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

mas

 export default 4; export var foo = 5; 

então

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

Para os autores da biblioteca, você poderá contornar esse problema.

Eu geralmente tenho um ponto de input, index.js , que é o arquivo que eu aponto do campo principal em package.json . Não faz nada além de reexportar o ponto de input real da lib:

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

Para solucionar o problema do babel, alterei isso para uma instrução de import e, em seguida, atribuí o padrão a module.exports :

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

Todos os meus outros arquivos permanecem como módulos ES6 puros, sem soluções alternativas. Então, apenas o ponto de input precisa de uma mudança ligeiramente 🙂

Isso funcionará para o commonjs, e também para as importações do ES6, porque o babel não parece ter perdido a interoperabilidade reversa (commonjs -> es6). Babel injeta a seguinte function para consertar o commonjs:

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

Passei horas lutando com isso, então espero que isso poupe o esforço de outra pessoa!

Eu tive esse tipo de problema. E esta é minha solução:

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