Wcześniej babel dodawał linię module.exports = exports["default"]. Już tego nie robi. Co to oznacza, zanim będę mógł:

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

Teraz muszę to zrobić:

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

Nie jest to wielka sprawa (i myślę, że tak powinno być przez cały czas). Problem polega na tym, że mam dużo kodu, który zależał od sposobu, w jaki rzeczy działały (większość mogę przekonwertować na import z ES6, ale nie całość). Czy ktoś może mi dać wskazówki, jak sprawić, by stary sposób działał bez konieczności przechodzenia przez mój projekt i naprawiania tego (lub nawet instrukcja, jak napisać codemod, aby to zrobić, byłaby całkiem sprytna).

Dzięki!

Przykład:

Wejście:

const foo = {}
export default foo

Wyjście z Babel 5

"use strict";

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

Wyjście z Babel 6 (i wtyczką es2015):

"use strict";

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

Zauważ, że jedyną różnicą w danych wyjściowych jest module.exports = exports["default"].

Edytować

Możesz być zainteresowany tym postem na blogu, który napisałem po rozwiązaniu mojego konkretnego problemu: Niezrozumienie modułów ES6, Uaktualnienie Babel, Łzy i rozwiązanie

Możesz także użyć tej wtyczki, aby przywrócić stare exportzachowanie.

Jeśli chcesz zachować zachowanie eksportu CommonJS, musisz użyć bezpośrednio CommonJS (lub użyć wtyczki w drugiej odpowiedzi). To zachowanie zostało usunięte, ponieważ powodowało zamieszanie i prowadziło do nieprawidłowej semantyki ES6, na której niektórzy polegali np

export default {
  a: 'foo'
};

i wtedy

import {a} from './foo';

który jest nieprawidłowy ES6, ale działał z powodu opisywanego zachowania współdziałania CommonJS. Niestety obsługa obu przypadków nie jest możliwa, a zezwolenie ludziom na pisanie nieprawidłowego ES6 jest gorszym problemem niż zmuszanie do tego .default.

Innym problemem było to, że było to nieoczekiwane dla użytkowników, jeśli na przykład dodali nazwany eksport w przyszłości

export default 4;

następnie

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

ale

export default 4;
export var foo = 5;

następnie

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

W przypadku autorów bibliotecznych możesz obejść ten problem.

Zwykle mam punkt wejścia index.js, czyli plik, na który wskazuję z głównego pola w package.json. Nie robi nic poza reeksportowaniem rzeczywistego punktu wejścia biblioteki:

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

Aby obejść problem z babel, zmieniłem to na importinstrukcję, a następnie przypisałem wartość domyślną do module.exports:

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

Wszystkie moje inne pliki pozostają jako czyste moduły ES6, bez żadnych obejść. Więc tylko punkt wejścia wymaga nieznacznej zmiany :)

To zadziała dla wymagań commonjs, a także dla importu z ES6, ponieważ babel nie wydaje się porzucić odwrotnej interop (commonjs -> es6). Babel wprowadza następującą funkcję, aby załatać commonjs:

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

Spędziłem godziny walcząc z tym, więc mam nadzieję, że zaoszczędzi to komuś innemu wysiłku!

Miałem taki problem. A oto moje rozwiązanie:

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