Consider supporting `__esModule` flag on CommonJS

[guybedford]

CommonJS modules that have the defineProperty(exports, '__esModule', { value: true }) thing could potentially be inferred as ES modules automatically in Rollup, and their exports bindings treated as such. Almost a sort of reverse CommonJS -> ES6 transformation. This would allow any modules transpiled with Babel into CommonJS to support Rollup optimizations due to their bindings nature.

This would greatly improve Rollup's ability to inline modules, as a sort of alternative to the jsnext:main thing.

Just sending the idea along though, feel free to close.

[Victorystick]

It's a good idea, for sure. More npm modules are available as CommonJS processed by Babel than are proper ES modules. See rollup/rollup-plugin-commonjs#10, rollup/rollup-plugin-commonjs#16 and rollup/rollup-plugin-commonjs#29 for some Babel/CommonJS related issues.

This issue, if handled, should probably be done by the CommonJS plugin. Or an un-babel plugin, that assumes it's working with code that used to be proper ES modules.

[fregante]

Not only supporting, but also exporting it. My CJS rollup exports are not being recognized correctly by babel because its version of _interopDefault only checks for the __esModule property.

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

Source: https://github.com/babel/babel/blob/5b89849f432cfc034860f495b5001039123e7754/packages/babel-helpers/src/helpers.js#L238-L242

[Nathan-Wall]

I'm trying to set up a system where I can write code using ES2015 modules, transform to AMD for development, and Rollup to a bundle for deployment. Having Rollup, Babel, and RequireJS understand each others output better would be helpful for me. I think this would be a good step.

[eventualbuddha]

Rollup does now output this flag. Whether the CommonJS plugin handles it specially I don't know.

[Rich-Harris]

Will close this as recent versions of rollup-plugin-commonjs handle transpiled modules