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

v0.14.27 breaks bundle with outdent module #2103

Closed
fisker opened this issue Mar 15, 2022 · 7 comments
Closed

v0.14.27 breaks bundle with outdent module #2103

fisker opened this issue Mar 15, 2022 · 7 comments

Comments

@fisker
Copy link

fisker commented Mar 15, 2022

Should be caused by #2059

This from outdent module will override the module.exports.

Reproduce repo https://github.com/fisker/esbuild-0-14-27-issue

@evanw
Copy link
Owner

evanw commented Mar 15, 2022

This is a problem with that package, not with esbuild. You are not supposed to use both CommonJS module exports and ES module exports in the same file. When you reference module in an ES module, the module reference is treated as a global reference and may collide with other code. If you bundle with --log-level=debug you'll see esbuild calling out the problem:

● [DEBUG] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected

    node_modules/outdent/lib-module/index.js:165:8:
      165 │         module.exports = defaultOutdent;
          ╵         ~~~~~~

  This file is considered to be an ECMAScript module because of the "export" keyword here:

    node_modules/outdent/lib-module/index.js:160:0:
      160 │ export { defaultOutdent as outdent };
          ╵ ~~~~~~

@fisker
Copy link
Author

fisker commented Mar 15, 2022

I agree that module should be treat as a global variable, so why don't we replace it with globalThis.module or just throw an error instead of this debug info?

@evanw
Copy link
Owner

evanw commented Mar 15, 2022

Most warnings for files inside node_modules are debug messages instead of warnings. One reason is because the warning isn't immediately actionable, since the person seeing the warning has no way of fixing the problem (only the package author can fix the problem). Another reason is because every time I add a warning that triggers for files inside node_modules, someone ends up filing an issue telling me to remove it. So I have been making them debug messages instead of warnings.

@evanw
Copy link
Owner

evanw commented Mar 15, 2022

I'm going to close this issue since I consider this case to basically be undefined behavior, and I think esbuild's output here is reasonable. The correct fix here is for the package author to not do this.

@evanw evanw closed this as completed Mar 15, 2022
@fisker
Copy link
Author

fisker commented Mar 15, 2022

why don't we replace it with globalThis.module

What's your opinion on this?

@evanw
Copy link
Owner

evanw commented Mar 15, 2022

I don't think that should be done because globalThis is a recent addition to JavaScript, and polyfills for globalThis that work in all JavaScript environments are surprisingly complicated. It seems like a lot of work and maintenance overhead to support something that no one should be doing anyway.

@fisker
Copy link
Author

fisker commented Mar 15, 2022

How about rename it to something like __globalModule__? So this can throw on runtime, or if someone really mean to use the global variable module, it can be fixed by add getter/setter to globalThis before load the bundle. Sorry for those silly suggestions, but I really hate it silently change the module exports.

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

2 participants