Avant, babel ajoutait la ligne module.exports = exports["default"]. Il ne fait plus cela. Ce que cela signifie, c'est avant que je puisse faire:

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

Maintenant, je dois faire ceci:

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

Pas une grosse affaire (et je suppose que c'est ce que cela aurait dû être tout au long). Le problème est que j'ai beaucoup de code qui dépend de la façon dont les choses fonctionnaient (je peux en convertir la plupart en importations ES6, mais pas en totalité). Quelqu'un peut-il me donner des conseils sur la façon de faire fonctionner l'ancienne méthode sans avoir à passer par mon projet et à résoudre ce problème (ou même des instructions sur la façon d'écrire un codemod pour le faire seraient assez simples).

Merci!

Exemple:

Contribution:

const foo = {}
export default foo

Sortie avec Babel 5

"use strict";

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

Sortie avec Babel 6 (et le plugin es2015):

"use strict";

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

Notez que la seule différence dans la sortie est le module.exports = exports["default"].

Éditer

Vous pouvez être intéressé par cet article de blog que j'ai écrit après avoir résolu mon problème spécifique: les malentendus des modules ES6, la mise à niveau de Babel, les larmes et une solution

Vous pouvez également utiliser ce plugin pour récupérer l'ancien exportcomportement.

Si vous voulez un comportement d'exportation CommonJS, vous devrez utiliser CommonJS directement (ou utiliser le plugin dans l'autre réponse). Ce comportement a été supprimé car il a causé de la confusion et conduit à une sémantique ES6 non valide, sur laquelle certaines personnes se sont penchées, par exemple

export default {
  a: 'foo'
};

puis

import {a} from './foo';

qui n'est pas valide ES6 mais qui a fonctionné en raison du comportement d'interopérabilité CommonJS que vous décrivez. Malheureusement, la prise en charge des deux cas n'est pas possible, et permettre aux gens d'écrire ES6 non valide est un problème pire que de vous obliger à le faire .default.

L'autre problème était qu'il était inattendu pour les utilisateurs s'ils ajoutaient une exportation nommée à l'avenir, par exemple

export default 4;

puis

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

mais

export default 4;
export var foo = 5;

puis

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

Pour les auteurs de bibliothèque, vous pourrez peut-être contourner ce problème.

J'ai généralement un point d'entrée index.js, qui est le fichier vers lequel je pointe depuis le champ principal package.json. Il ne fait rien d'autre que de réexporter le point d'entrée réel de la lib:

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

Pour contourner le problème babel, j'ai changé cela en une importdéclaration, puis attribue la valeur par défaut à module.exports:

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

Tous mes autres fichiers restent des modules ES6 purs, sans solution de contournement. Donc, seul le point d'entrée a besoin d'un léger changement :)

Cela fonctionnera pour commonjs nécessite, et aussi pour les importations ES6 car babel ne semble pas avoir abandonné l'interopérabilité inverse (commonjs -> es6). Babel injecte la fonction suivante pour corriger les commonjs:

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

J'ai passé des heures à lutter contre cela, alors j'espère que cela fera économiser de l'effort à quelqu'un d'autre!

J'ai eu ce genre de problème. Et voici ma solution:

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