Babel 6 ändert die Art und Weise, wie es standardmäßig exportiert

Question 1

Früher fügte babel die Zeile hinzu module.exports = exports["default"]. Dies tut es nicht mehr. Was dies bedeutet, ist, bevor ich tun konnte:

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

Jetzt muss ich das machen:

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

Keine große Sache (und ich schätze, das ist es, was es die ganze Zeit hätte sein sollen). Das Problem ist, dass ich eine Menge Code habe, der davon abhing, wie die Dinge früher funktionierten (ich kann das meiste davon in ES6-Importe konvertieren, aber nicht alles). Kann mir jemand Tipps geben, wie ich den alten Weg zum Laufen bringen kann, ohne mein Projekt durchgehen und dies beheben zu müssen (oder sogar eine Anleitung, wie man einen Codemod schreibt, um dies zu tun, wäre ziemlich raffiniert).

Danke!

Beispiel:

Eingang:

const foo = {}
export default foo

Ausgabe mit Babel 5

"use strict";

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

Ausgabe mit Babel 6 (und es2015-Plugin):

"use strict";

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

Beachten Sie, dass der einzige Unterschied in der Ausgabe der ist module.exports = exports["default"].

Bearbeiten

Vielleicht interessiert Sie dieser Blogpost, den ich geschrieben habe, nachdem ich mein spezifisches Problem gelöst hatte: Missverständnisse bei ES6-Modulen, Upgrade von Babel, Tears und eine Lösung

Question 2

Wenn Sie das CommonJS-Exportverhalten wünschen, müssen Sie CommonJS direkt verwenden (oder das Plugin in der anderen Antwort verwenden). Dieses Verhalten wurde entfernt, da es Verwirrung stiftete und zu einer ungültigen ES6-Semantik führte, auf die sich einige Leute verlassen hatten, z

export default {
  a: 'foo'
};

und dann

import {a} from './foo';

Dies ist ungültiges ES6, funktionierte jedoch aufgrund des von Ihnen beschriebenen CommonJS-Interoperabilitätsverhaltens. Leider ist es nicht möglich, beide Fälle zu unterstützen, und es ist schlimmer, Leuten zu erlauben, ungültige ES6 zu schreiben, als Sie dazu zu bringen .default.

Das andere Problem war, dass es für Benutzer unerwartet war, wenn sie beispielsweise in Zukunft einen benannten Export hinzufügten

export default 4;

Dann

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

Aber

export default 4;
export var foo = 5;

Dann

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

Question 3

Sie können auch verwenden dieses Plugin um das alte zu bekommen export Verhalten zurück.

Question 4

Für Bibliotheksautoren können Sie dieses Problem möglicherweise umgehen.

Normalerweise habe ich einen Einstiegspunkt, index.jsdas ist die Datei, auf die ich vom Hauptfeld aus zeige package.json. Es tut nichts anderes, als den tatsächlichen Einstiegspunkt der Bibliothek erneut zu exportieren:

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

Um das babel-Problem zu umgehen, habe ich dies in eine geändert import -Anweisung und weisen Sie dann den Standardwert zu module.exports:

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

Alle meine anderen Dateien bleiben als reine ES6-Module ohne Problemumgehungen. Also muss nur der Einstiegspunkt etwas geändert werden 🙂

Dies funktioniert für commonjs-Anforderungen und auch für ES6-Importe, da babel die Reverse Interop (commonjs -> es6) nicht fallen gelassen zu haben scheint. Babel fügt die folgende Funktion ein, um commonjs zu patchen:

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

Ich habe Stunden damit verbracht, dagegen anzukämpfen, also hoffe ich, dass dies jemand anderem die Mühe erspart!

Question 5

Ich hatte so ein Problem. Und das ist meine Lösung:

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