esbuild@>=0.14.5 introduces a regression for __toESM(require('esbuild'))

[Kiyozz]

Versions
First repro	0.14.9
Also repro	latest, >=0.14.5
Not repro	0.13.x, <0.14.5
OS	Windows
Node/npm	17

Repro repository - use-tsup branch

1. git checkout f336527bb964c0933a25168b821f334bd52c7a55
2. pnpm i
3. cd packages/ee - pnpm prepublishOnly
4. cd ../electron-esbuild - pnpm prepublishOnly

Used command to build ee package : esbuild src/index.ts --outdir=dist --bundle --platform=node --external:esbuild --sourcemap. Note esbuild as external

CURRENT: Uncaught TypeError: Cannot read properties of undefined (reading 'build')
EXPECTED: no error

This is working with esbuild 0.14.3, redo all above with cd packages/ee - pnpm i -D esbuild@0.14.3

The problem is that esbuild changes the source from

import esbuild from 'esbuild'
...
esbuild.build({...})

to

var import_esbuild = __toESM(require('esbuild'))
...
import_esbuild.default.build({...})

But from esbuild@0.14.5, var import_esbuild = __toESM(require('esbuild')).default is undefined but not with esbuild@<0.14.5

Note that, this is working using import { build } from 'esbuild' because bundled source do not use import_esbuild.default.build but import_esbuild.build directly

[evanw]

This is because there's no export called default in esbuild's source code. Both your code and esbuild's code is in ES module format, so your code would be a run-time import binding failure if everything was run as ES modules. Everything is being run as CommonJS instead so there's no run-time import binding failure, but esbuild still emulates ES module semantics on top of CommonJS so doing this still won't work. You have a few options:

1. Don't use the default export, since it doesn't exist:

   import * as esbuild from 'esbuild'

2. Use require() instead of using import, which gives you the underlying import directly:

   import esbuild = require('esbuild')

3. Tell esbuild to compile the file build.ts in node compatibility mode, since node invents a default export in this case. You can do this by changing the file name to build.mts, which esbuild takes as a signal that it should use node's .mjs semantics.

[Kiyozz]

Yes, esbuild does not have a default export. But the job of __toESM is to add a .default in case the module does not have one? If so, import_esbuild.default should not be undefined. Am I wrong?

[hyrious]

esbuild is aligned to the babel/webpack behavior of es module interop since 0.14.5. That is to say, if a cjs file has __esModule: true, you will get the exports.default value when import default_value. This is for compatibility with other bundlers and keeping the es modules semantic consist regardless of platform (node/browser).

In fact, node's behavior is getting more complex during the days. In node.js 17, importing a cjs module will give you not only the whole module.exports as default export, but also some named export guessing with cjs-module-lexer, while that's a runtime feature, bundler's can not repeat that.

In conclusion, esbuild (and other bundlers) will be consist with their esm interop rule when transforming esm to cjs. If you want to get the node.js behavior, why not just output esm (format: esm) and let node run that?

[evanw]

But the job of __toESM is to add a .default in case the module does not have one?

This is incorrect. The job of __toESM is to implement esbuild's ESM interop behavior. That behavior only involves overwriting the default export when the file is in node compatibility mode. Node compatibility mode is only enabled if the file extension is .mjs or .mts, or if the enclosing package.json file contains "type": "module". Otherwise, the behavior of a converted ESM import statement is designed to emulate the behavior of the original ESM code before the conversion.

[Kiyozz]

Thanks both of you. It must bo clear that typescript's esModuleInterop cannot be used with esbuild. Because typescript will add the .default if the module does not defined a default, but esbuild will not (but code will compile and type check successfully). Is this something "normal" or a warn should be throwned?

[hyrious]

TypeScript doesn't add .default if __esModule is true, neither will he add default export if your input is in esm, Playground Link. The result cjs code is not able to run too.

[Kiyozz]

Okay!! I was missing the mod && mod.__esModule.

Shouldn't this version (0.14.5) have been a breaking change then?

[evanw]

Shouldn't this version (0.14.5) have been a breaking change then?

Perhaps. Technically every version is a breaking change for people relying on the old behavior. It's up to the publisher what is considered "bug fix" vs. "breaking change" even though bug fixes can break code that makes use of the bug. It seemed like a bug fix to me (specifically #1719, #1591, and #532).

[Kiyozz]

Shouldn't this version (0.14.5) have been a breaking change then?

Perhaps. Technically every version is a breaking change for people relying on the old behavior. It's up to the publisher what is considered "bug fix" vs. "breaking change" even though bug fixes can break code that makes use of the bug. It seemed like a bug fix to me (specifically #1719, #1591, and #532).

I would say, only in the case where the old behavior was not the good one. If in the first place, le old behavior was just a mistake in the implementation, then it is a breaking. But if the old behavior should have worked like the new one, then it is a bug.

[aminick]

Currently experiencing this with "styled-components" too, which as a popular library, I suspect a lot of people have the same issue? upvote if you do, or I made a mistake on my end.

Setup:

"styled-components": "^5.3.3"
"tsup": "^5.11.11",
"vite": "^2.7.2"

Im using tsup to bundle the library, thus im here.

I suspect this is causing the issue?