Extending Error is flaky because Error.call returns a new object

[marijnh]

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 getting stack and message 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.

[marijnh]

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.

[Rich-Harris]

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?

[marijnh]

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.

[adrianheine]

As discussed in the babel issue, whether extending builtins is allowed should probably be configurable, right?

[adrianheine]

As @Andarist pointed out in #93, CompileError already sets message and stack, so this should not be a problem for bublé itself.