why esmodule set to false?

[hardfist]

export const a = 10;
export const b = 10;

will generates following in microbundle, which missing __esModule flag 1.

// lib1.js
exports.a=10,exports.b=10;
//# sourceMappingURL=index.js.map

while using rollup generates the folloing code,which seems more accurate 2.

// lib2.js
'use strict';

Object.defineProperty(exports, '__esModule', { value: true });

const a = 10;
const b = 10;

exports.a = a;
exports.b = b;

which both works fine in the following

const { a,b } =require('lib')
console.log(a,b);

but behaves differently in the following code

import lib1 from "./lib1";
import lib2 from "./lib2";

console.log("lib1:", lib1); // lib1: { a:1,b:2}
console.log('lib2:',lib2); // lib2: undefiend

which lib2 seems more accurate

[developit]

The CommonJS output is CommonJS, not ES Modules. ES Modules consumers should use the ES Modules output. Microbundle tells you to set up your package.json so that this is the default in all bundlers:

{
  "main": "dist/lib.js",
  "module": "dist/lib.module.js"
}

[hardfist]

It works for project using webpack or rollup, but seems doesn't work for node typescript project which only use tsc and doesn't consume module field

[DaniAkash]

@hardfist Indeed! I followed this workaround but this causes my library to not work in TypeScript environments...

[developit]

FWIW Microbundle used to detect name-only and default-only exports and remove __esModule only in those cases. It's possible we need to provide an option to bring that behavior back.

[hardfist]

FWIW Microbundle used to detect name-only and default-only exports and remove __esModule only in those cases. It's possible we need to provide an option to bring that behavior back.

why remove __emModule

[huozhi]

consider make esModule as an option or param in CLI?

[wardpeet]

@huozhi Could you explain a little bit more about the use case? Are you targeting node 14?

[huozhi]

@wardpeet the purpose is to use esmodule syntax import with cjs bundles. usually cjs assets define a property __esModule to work compatiable with interpolate import. but pure cjs (disable esModule config) will erase property __esModule that breaks import on cjs files.

import defaultExportLib from 'lib' // this won't import the default export variable from 'lib' when use pure commonjs format

typescript has an option esModuleInterop to enable this module transform behavior, which define __esModule property on the target modules. the generated assets will look like following:

function __export(m) {
    for (var p in m) if (!exports.hasOwnProperty(p)) exports[p] = m[p];
}
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
__export(require("./use-swr"));
var use_swr_1 = __importDefault(require("./use-swr"));

I also saw tsdx has used the similar approach that when compilerOptions.esModuleInterop is set to true it will turn on esModule flag on rollup side. https://github.com/formium/tsdx/blob/462af2d002987f985695b98400e0344b8f2754b7/src/createRollupConfig.ts#L102

I feel this will be a lovely feature that microbundle could have. not for ts only, js assets can also could adopt this by CLI command like microbundle --esmodule-interop

[developit]

The options for this changed dramatically in recent @rollup/plugin-commonjs versions. There are some new ones that are perhaps more reasonable generated output that we could consider. The reason we have had this disabled is because a blanket assumption that all CJS modules are in fact compiled ESM produces suboptimal output to fix a tiny percentage of modules/usage patterns.

[huozhi]

@developit for ts assets, @rollup/plugin-commonjs won't be applied to them. since the compilation process is almost fully relied on ts compiler, wonder if microbundle support ts to respect tsconfig.compilerOptions.esModuleInterop?