-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow pure ECMAScript block #1644
Comments
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. |
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/). |
@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. |
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. |
|
But still not in the official installer and VS integration :) |
1.4 was released today and it's definitely in there. |
@danquirk That's great ! |
@NN--- that's correct. |
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:
The text was updated successfully, but these errors were encountered: