Clarify what environments are targeted by buble's codebase about buble HOT 8 CLOSED

@Rich-Harris what do you think? Since IE11 doesn't support classes, #66 and #40 are relevant here, too. I would say bublé should only be compiled for node 4.

from buble.

Maybe you could transpile with node4 support in mind for main entry and for the browser it could be transpiled down to es5? Although Im not sure what to do about module entry - at the moment its mainly targeting browsers too (as its understood by bundlers), but maybe some people somehow bundle for node too? 🤔 Would be actually good to have browser:module/module:browser 😂

from buble.

@adrianheine WDYT about the proposed solution of transpiling with different targets in mind for main and browser fields?

from buble.

I think that makes sense. We would have to find a workaround for #40, though.

from buble.

Imho that's a separate issue, that could ofc be fixed/tackled somehow but it is not tightly coupled to this one - or am I missing something?

from buble.

It is coupled, because transpiling classes will make our errors not have a message or a stack, so we would basically break the browser build.

from buble.

Hm, I can't be sure about all old browser, but you assign custom stack property here and it is readable in latest Chrome (when using transpiled version of CompileError class). Ain't sure about description because I don't know origin of this property - you do not specify it in CompileError's constructor nor it is built-in property of native Error. Maybe you had some other prop in mind?

most.js has migrated to transpiled version of buble's output (because they have migrated to babel which didnt support extending built-ins) for their custom DisposeAllError and it seems to work OK.

from buble.

Sorry, I meant message. It seems like you're right and CompileError already does what's necessary, so we should be able to do this.

from buble.