Open marijnh opened 7 years ago
Oh, even with that fix, the resulting instances are not instanceof
your class. Even Babel doesn't get that right.
It does work when you directly use class
syntax in the browser, so this is a case where compiling down does some damage.
Two possible fixes — don't transpile classes (#43), or don't transpile anything (#42). Depends whether we want to continue supporting Node 4. Any thoughts?
Ah, I wasn't even talking about this causing a problem in the Bublé sources (I hadn't noticed)—rather it was causing trouble in my own projects. But I've fallen back on directly writing the horrible ES5 code needed to create a subclass of Error for now, and I guess I'll just keep doing that until the next geological era when I can ship client-side ES6 code. So this isn't blocking me.
As discussed in the babel issue, whether extending builtins is allowed should probably be configurable, right?
As @andarist pointed out in #93, CompileError
already sets message
and stack
, so this should not be a problem for bublé itself.
I.e.
let x = {}; Error.call(x) == x
produces false, at least on Firefox and Chrome. This is preventing Error subclasses compiled with Bublé from gettingstack
andmessage
properties, making them rather useless.Babel works around this by creating a new binding to replace
this
inside the constructor, storing the result of the super constructor call in that, and returning it at the end. Would that be something that Bublé would be interested in adding? I might be able to create a PR.