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

Unconditional treatment of requires can be problematic for some libraries #2033

Closed
cfv1984 opened this issue Feb 18, 2022 · 3 comments
Closed

Comments

@cfv1984
Copy link

cfv1984 commented Feb 18, 2022

Hi!

Before I go on I just wanted to say: Thanks for the amazing work! esbuild is changing the way I do things and wanted to take the opportunity to thank you for it.

The thing I noticed:

It is, in CommonJS, semantically possible to not care for wether some require calls will succeed or not, and it has legitimate uses, which esbuild does not seem to contemplate when running with --bundle.

I noticed this when I first tried to use koa-views in a toy project of mine, which in turn uses consolidate.js.

consolidate presents an unified interface to many template engines but does not present any of them as dependencies, it is on the end user to add the one template engine they'll be using, and the library will expose the correct interface with the correct require for it inside.

This, however, seems to present a problem to esbuild, which correctly complains that none of this tens of libraries is there and I should mark them as external. This, given the number there is of them and the possibility that they will keep growing, can be a bit of an issue.

I believe the issue itself to come from the fact that they are dynamically required? It would be pretty cool if esbuild could instead, possibly through some --handle-conditional-requires flag, statically notice that this calls could potentially not end up happening and silently wrapped them in a mute try/catch or something along those lines.

@evanw
Copy link
Owner

evanw commented Feb 18, 2022

You could potentially work around this problem yourself by writing a plugin: https://esbuild.github.io/plugins/#on-resolve. Your plugin could somehow treat all missing dependencies of that library as external. I also added a comment in the linked issue about a simple way they could fix this for all of their users by moving the require() calls into the try statements.

@cfv1984
Copy link
Author

cfv1984 commented Feb 19, 2022

Thanks! Will do.

@evanw
Copy link
Owner

evanw commented Apr 4, 2023

I'm closing this because it's working as intended. This limitation is documented here: https://esbuild.github.io/api/#non-analyzable-imports.

@evanw evanw closed this as not planned Won't fix, can't repro, duplicate, stale Apr 4, 2023
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