Support __esModule marker from babel&co.

A lot of code on npm is ESM code that was rewritten by babel or others to be compatible with CommonJS. Not all packages publish ESM+CommonJS. The code will contain a special __esModule marker on the exports which Closure currently does not support. webpack and others use this to enable a smoother interop between ESM/CommonJS.

Example:

export let foo = 1;

is rewritten to

"use strict";

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

In webpack you can now import { foo } from "..."; just fine since they detect the __esModule marker (in non-strict mode).

Currently when using the rewriting facilities from Closure prevent this from working at all since it treats the code as CommonJS and rewrites everything to .default meaning that you can only do import X from "..."; and then X.foo. Unfortunately this breaks many npm packages that seem to rely on the webpack style interop.

I’ll try to create a proper reproducible example with some example npm packages but wanted to discuss this first. Maybe this has come up internally or some decision to not support this was already made.

webpack has documented there behaviour here and the case that is currently problematic is A2. (The document uses dynamic import() but the static import ...; acts the same).

Thoughts?

[ChadKillingsworth]

I just encountered this myself - and it wasn’t pleasant to work around.

I think a path forward here my be to recognize these modules and switch the exports back to ES module export statements.

[garrett-hopper]

Thanks, @ChadKillingsworth! After building the closure compiler from source and then building the clojurescript compiler to use it, everything seems to be working as expected. 😃 Thanks for all your help too, @thheller!