What's the planned behavior going forward?

@cesarandreu To always export a default to exports.default.

@sebmck Is this in reference to the issue discussed in #2047? I've been finding myself agreeing with
@UltCombo that that behavior can be a headache.

👍
Adding .default to your CJS require()s can be slightly bothersome, but not nearly as much as having an unexpected breaking change due to simply adding a named export to the imported module.

@jmm Not really. It's the fact that people are (wrongly) doing:

a.js

import { foo, bar } from "./b";

b.js

export default {
  foo: "foo",
  bar: "bar"
};

And Babel is letting them.

@sebmck That's just another symptom of bad implicit magic, imho. If you add a named export to b.js then it will be a breaking change to a.js (although it should be broken since the beginning).

@sebmck Oh ok, I wasn't aware of that behavior. 👍 to killing that off (obviously).

Hi! first, thanks for all the hard work and excellent tool. is the idea that commonJS consumers would need to require().default for all modules compiled with Babel? Reduced magic is nice, but that seems like it would be a deal breaker for folks publishing to the node ecosystem where such a convention doesn't exist. Perhaps it's worth it but if it's helpful feedback, I think if that was the behavior I'd stop using the module syntax rather then ask consumers to use .default.

@jquense or you can tell the consumers to prefer the ES2015 module syntax over the CJS one. 😉

@UltCombo, I really can't tell anyone building a node app to also use Babel to transpile their app to avoid some non idiomatic import with my module. they just won't use my module instead

@jquense I don't really see a problem as long as the API usage is properly documented for CJS and ES Modules. You may as well use a named export to give a more meaningful property name than default.

It's just not idiomatic, it breaks expectations and is a hassle (albeit a small one) for consumers. for packages that provide a lot of modules, asking ppl to remember the name of a bunch of single export module names is an unnecessary burden. ultimately I am not going to over complicate an API surface just so I can use the es6 module syntax. I appreciate that others are willing to make that tradeoff, I just wanted to provide feedback that I would not, hoping that it provides a helpful perspective :)

If you really want to use ES Modules syntax without having to ask your CJS consumers to add .default after the require() call, you can re-export it in your package's entry point:

module.exports = require('./transpiled/index').default;

@UltCombo @jquense Since I was mistaken about the subject of this issue, how about we continue discussion of the module.exports = exports["default"] behavior in #2047.