Make let default work even better

[chenglou]

So apparently aside from let default = ... to export a default to be imported by babel/webpack through es6, we also need let __esModule = {value: true} also exported. I'm guessing this is how the es6 import of babel and such detect es6 modules?

cc @JasonRose

[anmonteiro]

this looks too much like an implementation detail. I wonder if there's an alternative

[sansthesis]

Yes, https://babeljs.io/docs/plugins/transform-es2015-modules-commonjs/ describes the transform. microsoft/TypeScript#3586 is where typescript added support (although they've had some drama about it recently).

[bobzhang]

@chenglou did you hit this case in practice

[chenglou]

Jason did (at Instagram). Their setup is rather idiomatic webpack/babel I think?

[bobzhang]

So only when you use default export you need mark such property? Is this property a standard or just convention used by babel?

[IwanKaramazow]

It's something very specific to Babel as far as I know.

[glennsl]

I've hit it. Real-life example here: https://github.com/glennsl/reasonable-gatsby-starter/blob/master/src/layouts/layouts_index.re#L73. Gatsby uses Babel to transpile es6 to es5 before bundling with webpack. So while I could avoid this by using es6 package-specs, it needs to be set to emit commonjs for webpack to be able to pick up the dependencies, since they aren't transpiled.

I've also seen several others needing to do this on Discord.

[bobzhang]

so, if we detect default exported we instrument let __esModule = {value: true}, will that work for you? or shall we instrument let _esModule for every module

[sansthesis]

I could be wrong, but I think that it is only exercised in the context of default imports. http://2ality.com/2015/12/babel-commonjs.html#default-imports is a code snippet that shows what gets generated when someone tries to do a default import with babel. So without knowing more, I think that it makes sense to only include the code when bsc would emit exports.default = ...;

[bobzhang]

@JasonRose we can move forward with it, do you have a minimal way to confirm that intrument Object.defineProperty(exports, "__esModule", { value: true }); indeed solves the problem, otherwise broken. Thanks

[bobzhang]

For people who are interested, here is my discovery, (apparently it is a babel-specific issue)

import foo from "foo"

var u = foo

var _foo = require("foo");

var _foo2 = _interopRequireDefault(_foo);

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

var u = _foo2.default;

export default foo

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

I think adding

exports.__esModule = true 

should be good enough, let me know what you think? IIRC, Object.defineProperty is terribly inefficient

[andreypopp]

Just as a data point: webpack does the same — https://github.com/webpack/webpack/blob/master/lib/dependencies/HarmonyCompatibilityDependency.js#L24

[sansthesis]

I believe that they use Object.defineProperty to make it not appear when enumerating keys on the exports object, which could cause issues.

[bobzhang]

fixed in #2002 note that I did not use Object.defineProperty since exports is not designed to be enumerated on JS side, let me know if it works for you