Regarding behavior of @babel/plugin-transform-export-namespace-from:

[ayjayt]

I just left this note in a file for a graph library, hoping to get some insight to my confusion:

const version = '2.1.14-pre';
export default version;

try {
  module.exports = version;
} catch (e) {
  // We have to support .cjs in our .mjs ESM file because babel's transpiler
  // can't make the following leap:
  //
  // ESM we write:
  //   export default 3;
  // CJS we want:
  //   module.exports         = 3;
  // CJS we get:
  //   module.exports.default = 3;
  //
  //
  // FYI, the consumers:
  //
  // CJS:
  //   const myNum = require('./file.js')
  //
  // ESM equiv:
  //   import myNym from './file.js';
  //
  // The grammar is so similiar!
}

So basically, the original file is:

module.exports = 3;

The ESM rewrite is:

export default 3;

But the babel transpilation is:

"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.default = void 0;
var _default = exports.default = 3;

Which doesn't function equally.

[nicolo-ribaudo]

For ESM, "default" is just a named export that has some different syntax. You can see if you do, for example (without transpiling):

let a = 1;
export { a as someName, a as default };

console.log(await import("./that-file"));

that default is just a property together with someName on the object containing all the exports of that module.

[ayjayt]

But I think the transpiling should recognize that a single default export is NOT intended, when consumed by CJS, to be a named default. Because in CJS, it is not.

[nicolo-ribaudo]

Right, but if this just export default 1; produces module.exports = 1 and export default 1; export const foo = 2 produces exports.default = 1; exports.foo = 2, then simply adding export const foo = 2 to your code would be a breaking change because it changes the result of require("your module") from 2 to an object.

The way export default is transpiled must not depend on whether or not the file has other named exports, for the above reason.

[ayjayt]

I'm going to add a pull request for a config option to avoid named defaults. It's a practical solution for a real problem in several repositories I'm working on.

I like your analysis but I think the issue is that

then simply adding export const foo = 2 to your code would be a breaking change because it changes the result of require("your module") from 2 to an object.

is already a breaking change in a large portion of use contexts.

It is good where new libraries use babel to create cjs for consumption and users have learned to expect a named default. And certainly if you have or are planing on exporting multiple things from a single file, then the default must be named.

But in the case where we're trying to update old libraries for consumption by both modern and legacy frameworks, we need some manner of supporting transpilation to a true cjs-style default export.

So what I'm thinking of is a config option on either @babel/plugin-transform-export-namespace or on @babel/plugin-transform-modules-commonjs like avoidNamedDefault which would, yes, recognize a file w/ only one default export and then set it directly to modules.exports. And it could also throw warnings if it has to bail out of that due to multiple exports.

[liuxingbaoyu]

Seems related to #12363.

[nicolo-ribaudo]

No need for an option, you can use https://www.npmjs.com/package/babel-plugin-add-module-exports :)