fix(linker): add missing esm flag

[lbwa]

fix #1333, fix #1323

why

This pr is related to a backward-incompatible change from 0.11.0(changelog).

esbuild now generates transformed code like this:

var esm_file_exports = {};
__export(esm_file_exports, {
  default: () => defaultValue, // caution
  foo: () => foo
});
var foo;
var init_esm_file = __esm(() => {
  foo = bar();
});

The problem is esm_file_exports will be treated as a commnjs export when there is no __esModule flag. As for __importDefault, our esm default export will be treated as a normal commonjs export named default that we need to interop default export manually.

so I suggest adding __markAsModule evaluation for making esm_file_exports include a __esModule flag. This is used to make __importDefault interop default esm export automatically, instead of manually importation.

var esm_file_exports = {};
+ __markAsModule(esm_file_exports)
__export(esm_file_exports, {
  default: () => defaultValue,  // caution
  foo: () => foo
});
var foo;
var init_esm_file = __esm(() => {
  foo = bar();
});

related pr/issues/commit

• f4a7308

[guybedford]

Please let's not add markers to ES modules. Rather lets fix this for commonjs importers with better branding checks for ESM.

[lbwa]

Please let's not add markers to ES modules. Rather lets fix this for commonjs importers with better branding checks for ESM.

Looking forward to a better solution.

[guybedford]

@lbwa I still don't understand the original issue - how is Webpack loading an ES module external in the first place? That is the mechanism that will be responsible for the real ES module interop in this case.

[lbwa]

@lbwa I still don't understand the original issue - how is Webpack loading an ES module external in the first place? That is the mechanism that will be responsible for the real ES module interop in this case.

There is a minimal reproduction in #1333 (comment).

Why is it necessary

Rollup has faced to the same problem in rollup/plugins#481 (comment) (especially section Importing ESM from CJS ) that was resolved in rollup/plugins#552. That is why I recommended to add a esm flag into product.

Comparison

Based on #1333 (comment) reproduction:

[evanw]

Please let's not add markers to ES modules. Rather lets fix this for commonjs importers with better branding checks for ESM.

This only comes up when importing ESM from CommonJS and that isn't something that any JS engine supports, so there's no precedent from JS engines to guide the implementation. The way this has historically worked is via Babel which adds __esModule so it seems reasonable to me to add it here like this. This is the standard "branding check for ESM."

I still don't understand the original issue - how is Webpack loading an ES module external in the first place? That is the mechanism that will be responsible for the real ES module interop in this case.

You don't need Webpack for this. Another example is TypeScript, which is often used in a one-file-at-a-time mode where all imports are external:

import x from 'y'
console.log(x)

That gets converted into this by the TypeScript compiler:

var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
const y_1 = __importDefault(require("y"));
console.log(y_1.default);

So if the file 'y' is an ES module that is converted to CommonJS by the bundler, y_1 will become { "default": y_exports } and if y_exports has a default property, you will then need to use y_1.default.default to access it.

[moltar]

Broke this package: jawj/zapatos#92

Not sure where the problem is, just adding it for reference :)

[guybedford]

@evanw that is fine as long as the flag remains fully internal and doesn't spill into ESM interfaces imported from native ESM, which was my only concern here.

[bjornstar]

It also broke this package: Chevrotain/chevrotain#1537

Both packages are using gen-esm-wrapper and hopefully it is fixed in v1.1.2 which filters __esModule from exports.