Question: how to make esbuild's import behavior compatible with tsc/node?

[vincentcr]

We're trying to transition from tsc to esbuild and there's one issue we're stumbling on: importing from a module always injects a default entry even if not present in the exporting module. This breaks code where we would iterate over the module's entries, as there's now a new, unexpected default: undefined entry. This doesn't happen in tsc.

Example:

// a.ts
export const x = 1;
export const y = 2;

// b.ts 
import * as a from './a'
console.log(Object.entries(a))

When compiled with tsc or ts-node, b.ts outputs:

[ [ 'x', 1 ], [ 'y', 2 ] ]

But with esbuild (command npx esbuild --platform=node --format=cjs src/*.ts --outdir=./build) I get:

[ [ 'default', undefined ], [ 'x', 1 ], [ 'y', 2 ] ]

From reading past issues it seems like this is to maintain compatibility with babel, but I wonder if there's a way to turn this behavior off?

[evanw]

No, I think what you're proposing should just be how it works by default. There's no need to add a flag for this. Babel's behavior matches the behavior you suggested, not esbuild's current behavior.

The problem is that when a CommonJS module is imported using import, esbuild's generated getter for default that forwards to the underlying exports.default property is always enumerable. Instead, it should only be enumerable if the underlying property exists and is enumerable. I'll fix this in the next release.

[vincentcr]

Perfect, thank you.