Hi,
I am using esbuild
to bundle the output of a large scala.js program. With --minify-syntax
turned on, I see TypeError: Illegal invocation
on various places. One on react requestAnimation
, another on console.log
. It is quite difficult to come up with a minimal reproduce. I am working on one but wonder if you have an idea on what to do.
Thanks
Hmm, it's hard to say. The only thing I can think of that could cause TypeError: Illegal invocation
is ES6 imports of CommonJS exports. Here's what I mean:
// file1.js
exports.rAF = requestAnimationFrame
// file2.js
import {rAF} from './file1.js'
rAF(() => {})
With esbuild that would be bundled into something like this:
var require_file1 = __commonJS((exports) => {
exports.rAF = requestAnimationFrame;
});
const file1 = __toModule(require_file1());
file1.rAF(() => {
});
I think this will cause TypeError: Illegal invocation
because the this
context for rAF
is file1
not window
. Arguably this is a bug with esbuild and a more correct bundle would look like this instead:
var require_file1 = __commonJS((exports) => {
exports.rAF = requestAnimationFrame;
});
const file1 = __toModule(require_file1());
(0, file1.rAF)(() => {
});
I've known about the potential for this problem for a bit but I haven't ever observed it actually coming up in practice. If this is the issue, I can definitely fix it. But I can't see how that would be affected by minification, so that's probably not it. It'd be great to be able to reproduce this, even if it's not a minimal reproduction. I can do the minimizing myself if I can reproduce the issue.
Edit: Wait, I just remembered something. Enabling --minify-syntax
triggers more aggressive dead code elimination that removes branches such as if (false) { ... }
. I bet that's the cause of the behavior difference somehow.
Thanks @evanw for the quick reply.
I am definitely mixing ES6 and CommonJS modules here.
@evanw I have a (not so minified) reproduce case here https://github.com/ngbinh/esbuild-minify . Please let me know if you need anything
Thanks for the reproduction case. It looks like it was a different but related issue. I'll push a fix for this sometime today.
Wow, thanks
is there a way for me to try the unreleased version?
You can compile esbuild yourself if you'd like. Just download the repo and run make
to generate the esbuild
binary. You will need to install the Go compiler first. Or you can run go build ./cmd/esbuild
if your environment doesn't have the make
command.
thanks, will try the latest version out
@evanw can verify that it fixes the problem in my repo.
Thanks for confirming. This fix was just published in esbuild version 0.6.6.
@evanw there seems to be a problem with pulling: /esbuild-linux-64-0.6.6.tgz: incorrect header check
What's the full error message? It probably says something like Invalid gzip data in archive from <url>
. This is likely the result of an attempted fix to #286.
I downloaded the package through our own public nexus server. The link is https://nexus.anduin.co/repository/anduin-npm/esbuild/-/esbuild-0.6.6.tgz and you can see the binary is corrupted somehow
Can you try again? I didn't realize registries can be hosted from non-root paths, so I added support for those in version 0.6.7.
0.6.7 works for me. Thanks
Most helpful comment
Thanks for confirming. This fix was just published in esbuild version 0.6.6.