Repository navigation
Allow pure ECMAScript block #1644
Description
Activity
What's wrong with just adding an ES6 compiler option? (e.g. #595)
There is nothing wrong with that but it takes time for implementing the full ES6 spec.
Also think about future, ES7 would have new features, perhaps new syntax.
This will allow to mix in one file TS and new ES syntax.
Currently I have to split my code into consts.js for 'const' syntax and myfile.ts for the rest.I believe that is the idea see #904. It's not about down-level emit.
As I said it is not only about const or ES6, it is about any future feature to be used natively in TS without adding additional ES files until TS supports it natively.
One may use async/await in that block and give the compiled result to other converter for ES6. 👍
Curious what platforms you're targeting where you're using some of these features already given the sparse support I see so far (http://kangax.github.io/compat-table/es6/).
Dan Quirk (@danquirk): no need for platform support, you can transpile your code, e.g. using 6to5. Those features make your dev experience much better. BTW, IE12 is expected to come out early this year and have complete ES6 support. You can expect the other browsers to follow suit.
I think I opened #1641 for the same ground reason: TS is great but its lack of ES6 features is getting more and more frustrating :( For big new projects I'm torn between TS and ES6/7...
👍 e.g. the following
__ecmascript { function *foo() { yield 1; } }
would emit the following and not do any type checking
function *foo() { yield 1; }
It can be useful for the use cases already mentioned (i.e. using an alternative ES6 transpiler) plus also helps with bringing in JS codebases into a TypeScript file without seeing all the red lines.
I fear this may leave the codebase open to abuse:
__ecmascript { // Can't be bothered to annotate }
When compilation is permitted to have holes cut out, confidence in the system will be undermined.
I agree opening holes like that is denying a lot of benefits of having a complete Typescript codebase with "no implicit any" option activated. Good bye safe refactorings and find all references.
Moreover it's ugly and clearly a temporary hack until the language improves (but then you're stuck with it).
As much as I want TS to improve quickly towards ES6 compliance, this doesn't seem like a good idea to me.
ES6 features are coming online in the compiler pretty quickly (stay tuned). ES7 is supposedly going to have less new syntax than ES6 so I don't think this is going to be as much of an issue going forward. ES8, well, who knows, but we can see what that looks like when it gets closer.
ES6 features are coming online in the compiler pretty quickly (stay tuned)
This is awesome news! Thanks.
For reference, you can see some of them here https://github.com/Microsoft/TypeScript/issues?q=is%3Aissue+label%3AES6+is%3Aclosed
We are waiting.
The most needed feature for me are 'const' and 'let' .letandconstwere added in October #904But still not in the official installer and VS integration :)
1.4 was released today and it's definitely in there.
NN (@NN---) you would need to add lib.es6.d.ts explicitly to your project, see #1696 for details.
Dan Quirk (@danquirk) That's great !
There are no const enums for strings still, right ?NN (@NN---) that's correct.
- locked and limited conversation to collaborators
on Jun 18, 2018
Motivation:
TypeScript currently doesn't support all ES6 features and it takes time for supporting them.
Moreover each vendor plays with new ES extensions like ES7 draft and so on.
Proposal:
Allow pure ECMAScript block which is not treated as TypeScript.
It is pretty similar to '_asm' directive in C language.
This allows to use generators of ES6 while TS doesn't support them:
Or 'const' which is not supported in TS 1.3: