Question regarding mixing default and named exports

[transitive-bullshit]

I have a react module boilerplate which makes use of rollup, and some users are requesting the ability to export multiple components.

I'm bundling to cjs and es formats (rollup.config.js), so including both named and default exports from my bundle should be fine as I understand it, but rollup prints a warning about the use of mixed default and named exports.

import Foo from './Foo'
import Bar from './Bar'

// export Foo and Bar as named exports
export { Foo, Bar }

// alternative, more concise syntax for named exports
// export { default as Foo } from './Foo'

// you could also export a default object containing your module's interface
// note that if you export both named and default exports, rollup will complain.
// if you know how to prevent this warning, please let me know :)
// export default { Foo, Bar }

For more context, see this thread.

In particular, I can see why this would be a problem for umd bundles (source), but I'm not sure why rollup is complaining for es and cjs bundles.

Any idea how we could resolve this issue?

[TrySound]

@transitive-bullshit I'm sure warning is quite descriptive and ask you to use explicit option to determine behavior.

[transitive-bullshit]

Yep, the option docs were just a bit confusing, but changing my output to use exports: 'named' did the trick.

Thanks!

[transitive-bullshit]

The docs state:

It is bad practice to mix default and named exports in the same module, though it is allowed by the specification.

I'd love to get some clarity on why this is considered a bad practice because empirically this is how many top-level libraries provide their exports.

Thanks!

[lukastaegert]

It is not really a problem if you export to ESM (though some consider it bad style) but it definitely is a problem if you export to CJS and your consumer is not using a bundler.

As CJS only has a single exports or module.exports object, there is no concept of a default export other than assigning it directly to module.exports. In which case it is not possible to add additional named exports. Rollups exports: auto module illustrates this dilemma:

// only a default
// ESM input
export default 42;

// CJS output
var main = 42;
module.exports = main;

// only named
// ESM input
export var a = 42;

// CJS output
Object.defineProperty(exports, '__esModule', { value: true });
var a = 42;
exports.a = a;

Now if I would add a default export in the second case like I did in the first place, this would replace all named exports. Which is why the following happens if you add a default export:

// mixed
// ESM input
export var a = 42;
export default 42;

// CJS output
Object.defineProperty(exports, '__esModule', { value: true });
var a = 42;
var main = 42;
exports.a = a;
exports.default = main;

So your default export is added as a default key to your export and if someone requires your file directly in node, they will need to access the default via this property. Which is probably weird and counter-intuitive.

However if people use a bundler and ESM, they will not notice this because the __esModule property is used as a flag to tell the bundler: This was transpiled from ESM using named exports mode, if someone does a default import, just give them whatever is at the default key. But it is inconsistent with what happens for direct node consumers.

As for the "bad style": There are many articles describing the disadvantages of default exports, e.g. https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad
But for CJS, you want to directly control what require('x') gives you, and a default export seems to be the perfect match for this. Mixing both, however, gives you all the disadvantages without the advantages. Hopes this helps a little.

[transitive-bullshit]

Really appreciate the thorough answer @lukastaegert -- thanks so much!

[TrySound]

I even prefer to omit default exports at all.

[morewry]

I think this is only true depending on the type of the default export. If it's a function or class (e.g. constructor function), no big.

I have done both of these in CJS:

module.exports = function () {};
module.exports.foo = 'bar';

class Stuff {
  constructor() {}
  static get foo() {
    return 'bar';
  }
}
module.exports = Stuff;

Both are easy to wrangle with ESM.