Override helpers about tslib HOT 8 OPEN

We have a proposal for __extends in microsoft/TypeScript#12488 that should work for IE10 as well as newer browsers.

from tslib.

I would say this should be done on the TS side of things. the compiler could allow an option for --importHelpers specifying the other library name, and it would import helpers from it, allowing you to have a custom import helper library.

from tslib.

Not sure you need to do anything like that. What you describe is basically what we've done until now: --noEmitHelpers +having my own file copied from github. The only difference is whether we use globals or a module but it doesn't matter much here.

The problem with this approach is that we have to copy the whole thing to modify just __extends. Updating our copy when you tweak the helpers is not good because it's hard to know when something changes.

BTW: maybe you could reconsider your position on __extends... As IE 10- is less and less relevant, I think the benefits of having standard compliant code-gen in widespread browsers is more important than being consistently incorrect on some edge cases.

from tslib.

The problem with this approach is that we have to copy the whole thing to modify just __extends. Updating our copy when you tweak the helpers is not good because it's hard to know when something changes.

you can still export * from tslib if you want.

BTW: maybe you could reconsider your position on __extends... As IE 10- is less and less relevant, I think the benefits of having standard compliant code-gen in widespread browsers is more important than being consistently incorrect on some edge cases.

I am sure you will have different feelings if you are supporting users on IE8, IE9 and IE10. We have heard feedback from multiple users who care about this scenario.

from tslib.

you can still export * from tslib if you want.

Good point!

I am sure you will have different feelings if you are supporting users on IE8, IE9 and IE10. We have heard feedback from multiple users who care about this scenario.

If I may:
(a) then maybe it would be nice to have a choice and being able to opt-in standard-compliant emit (e.g. with a flag on the command line).
(b) when I had to support IE8-10 (heck, I started with IE6), I was always sure to develop and test on the lowest version supported. We are talking about an edge-case that can't ever work in those browsers (so you better not depend on it even with the current emit). If your users support IE8-10 but never test with any of those three, then I wouldn't say they actually support IE10.

In the meantime... people who try to write standard-compliant code, or who try to migrate from Babel now that your downlevel emit is complete, have a really fun time debugging this stuff out. It takes a lot of time to understand why your Reflect.metadata polyfill doesn't seem to work, trust me I did.. several times 😆

from tslib.

Well, that proposal is great because it will be standard-compliant in IE11+ and it will fix issues in frameworks that use metadata when code is compiled to ES5. 🎉

But I should admit that I don't see how that would work for IE10-??
If I'm looking at the right code, you would be using setPrototypeOf or __proto__ when available. Neither of those are in IE 10-, so we'll keep on using the current strategy, which is copying the properties.

This is exactly what I've been asking for but I need to point out that you would introduce a different behavior between IE10- and IE11+, which I thought was exactly what you wanted to avoid.

from tslib.

that is the best we could come up with :) trying to keep existing code working as well.

from tslib.

that is the best we could come up with :)

No pressure! It's impossible to emulate inheritance in IE10- with 100% fidelity.

I am glad you changed your mind about having a different ES-compliant behavior in capable browsers! 😃

from tslib.