Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CJS requires don't work when bundled by ESM package #28

Closed
zvictor opened this issue Jun 23, 2022 · 2 comments
Closed

CJS requires don't work when bundled by ESM package #28

zvictor opened this issue Jun 23, 2022 · 2 comments

Comments

@zvictor
Copy link
Owner

zvictor commented Jun 23, 2022

Running tsup with the --format cjs option fails with an error for files importing faugra, but only when bundling from an ESM package (i.e. "type": "module"):

TypeError: (0 , import_faugra.default) is not a function
    at main (/faugra/examples/modularized/build/index.cjs:21:52)
    at Object.<anonymous> (/faugra/examples/modularized/build/index.cjs:32:1)
    at Module._compile (node:internal/modules/cjs/loader:1112:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1166:10)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Module._load (node:internal/modules/cjs/loader:834:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47

Running tsup index.ts --format cjs in our basic example (CJS) works, but running it in the modularized example (ESM) fails.

My statements are verifiable by automated tests:

These 2 issues seem to be related to it:

Manually editing the bundled file and replacing __toESM(require("faugra"), 1) by __toESM(require("faugra"), 0) fix the issue.

@zvictor
Copy link
Owner Author

zvictor commented Jun 23, 2022

This might be a workaround in some situations: TypeStrong/ts-node#935 (comment)

@zvictor
Copy link
Owner Author

zvictor commented Jun 23, 2022

So, after all, this behaviour is "by design".

From esbuild docs:

When code in the ESM format that has a default export is converted to the CommonJS format, and then that CommonJS code is imported into another module in ESM format, there are two different interpretations of what should happen that are both widely-used (the Babel way and the Node way). This is very unfortunate because it causes endless compatibility headaches, especially since JavaScript libraries are often authored in ESM and published as CommonJS.

When esbuild bundles code that does this, it has to decide which interpretation to use, and there's no perfect answer.

I had read it before, but unfortunately I hadn't really comprehended it.


My conclusion is that we need to give the option for users to import the sdk using a named import.
I will add that to the next release 🐣


Update: If you are facing TypeError: (0 , import_faugra.default) is not a function,
try replacing import faugra from "faugra" by import { faugra } from "faugra"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant