Repository navigation
Using ES6 type default library when targetting ES5 output #3005
Description
Activity
- changed the title
[-]Using ES6 type definition library when targetting ES5 output[/-][+]Using ES6 type default library when targetting ES5 output[/+]on May 2, 2015 This is something I've suggested a few times to Mohamed Hegazy (@mhegazy) and jonathandturner - right now we don't provide a good facility for this.
Right now the easiest thing to do is to manually include the
lib.es6.d.tsfile within the compiler directory, or even just grab it from our repo and put it in your source; but I agree that it's pretty ad-hoc.Ideally, there would be a
.d.tsfile for your polyfill library, probably adapted for our es6 typings. Out of curiosity, what polyfill library do you use?Out of curiosity, what polyfill library do you use?
I'm using es6-collections for Map and Set. For anything supported by IE >= 10 (eg. DataView) I'm not using anything. For Promise there are a long list of options and polyfills for that might not be needed much longer.
This is relevant in node/iojs scenarios too, but is broader than just .d.ts support. ES6 feature support is patchy in V8, some things are available and some aren't. It would be great if TSC could somehow support finer target granularity not just with the .d.ts, but also with emit. For instance I must set target=ES5 for node, but would like to tell the compiler to use ES6 emit for already supported things.
Case in point: I'm working with generators a lot at the moment and use a forked TSC that emits ES5 + generators (which are emitted just fine when targetting ES6).
This makes really big problem, as author of library which contains Promise polyfill I cannot define Promise myself or it will not be compilable in ES6 mode due to clash of Promise name or If I will not include it, it will not be compilable in ES5 mode. Referencing lib.es6.d.ts directly is also no go, as I cannot force my users to do same hack and reference my forked lib.es6.d.ts.
this is now tracked in #4168.
- locked and limited conversation to collaborators
on Jun 18, 2018
I'm building a project for 'modern' but not bleeding-edge browsers (IE >= 10, Chrome/Firefox from mid-last year onwards), this means targeting ES5 output since ES6 language features are incomplete. However I'm able to use many ES6 library features either via polyfills (Map, Set, Promise) or because browsers added support for them early on (eg. DataView is available in IE 10 and later).
At the moment the language and library targets in TSC are controlled by the same --target option, which makes this difficult, more so in TS 1.5.0-beta because a number of ES6 APIs that used to be in the lib.d.ts file (Map, DataView) are now only found in the ES6 library.
Some possible solutions:
#[stable(feature = "rust1", since = "1.0.0")]on a method to indicate which version of the library a method became available in. Compiler flags could then be used to allow or deny use of ES6 interfaces.Thoughts?