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
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.
The text was updated successfully, but these errors were encountered:
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.
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, whichesbuild
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 usesconsolidate.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 correctrequire
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 callscould
potentially not end up happening and silently wrapped them in a mutetry/catch
or something along those lines.The text was updated successfully, but these errors were encountered: