You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve encountered this bug with @sentry/browser + @sentry/utils and isolated it into the following.
Bug
If esbuild encounters the combination of export * from 'some-module' + some-module using the Node.js’ module object, it fails to bundle the code. E.g.:
The reason for this is that referencing module causes the file to become a CommonJS module, and the list of exports in a CommonJS module are not generally statically analyzable at bundle time. For example, you might have code that does this:
It's impossible to know at bundle time whether foo is exported or not because it depends on run time behavior.
I think this should be possible to fix, at least in most cases. The fix I'm thinking of is to have an export * from ... statement cause the file containing that statement to also become a CommonJS module if the exports come from a CommonJS module.
The only case where this might not be what you expect is if the export * from ... statement is in an entry point file and the format is esm. It should still work but it will cause the entry point to emit a single default export for the CommonJS export object instead of individual named exports, since the entry point will become a CommonJS module.
Hey!
I’ve encountered this bug with
@sentry/browser
+@sentry/utils
and isolated it into the following.Bug
If
esbuild
encounters the combination ofexport * from 'some-module'
+some-module
using the Node.js’module
object, it fails to bundle the code. E.g.:produces the following error:
If you replace
export *
withexport { getEventDescription }
, the build completes successfully:If you remove the
module
reference, the build completes successfully as well:// index.js import { getEventDescription } from './b.js'; console.log(getEventDescription); // b.js export * from './c'; // c.js export function getEventDescription() {} - console.log(module);
The
module
reference doesn’t have to live at the top level – e.g., in@sentry/utils
, it’s used inside an IIFE.Environment
Reproduced with the latest
esbuild
built frommaster
.Repro
→ https://github.com/iamakulov/esbuild-module-import-repro
To run the build:
The text was updated successfully, but these errors were encountered: