TypeScript parser #523
TypeScript parser #523
Conversation
Codecov Report
@@ Coverage Diff @@
## master #523 +/- ##
=========================================
- Coverage 98.27% 95.97% -2.3%
=========================================
Files 22 23 +1
Lines 3530 4477 +947
Branches 981 1240 +259
=========================================
+ Hits 3469 4297 +828
- Misses 22 86 +64
- Partials 39 94 +55
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #523 +/- ##
==========================================
- Coverage 98.14% 95.82% -2.33%
==========================================
Files 22 23 +1
Lines 3674 4695 +1021
Branches 1024 1287 +263
==========================================
+ Hits 3606 4499 +893
- Misses 25 107 +82
- Partials 43 89 +46
Continue to review full report at Codecov.
|
I think that should be covered by babel/babel#5511 but I didn't think we really wanted it earlier? |
|
I know it's easier to modify the code in src/expression etc, but is there a way for us to make the parser plugin like in estree/flow/jsx? https://github.com/babel/babylon/tree/master/src/plugins. The concern is how we are going to do versioning? In flow I guess everything is a minor/patch though. Maybe we can discuss is at the meeting (not typescript specific issue though) |
Change TSIndexSignatureDeclaration to TSIndexSignature
Change TSModuleBlock `.statements` to `.body`
…ypeParameterDeclaration[]
Use TypeParameterDeclaration and TypeParameter nodes instead of a TsTypeParameterDeclaration[]
Use TypeAnnotation node for type annotations
…ts may never have "name", others are TSNamedTypeElementBase
Add TSInterfaceBody intermediate node
Change "name" fields to "id" or "key"
Introduce TSDeclareFunction and TSDeclareMethod node types
src/parser/expression.js
Outdated
| node.generator = !!isGenerator; | ||
| this.parseFunctionBody(node); | ||
| const missingBody = this.maybeParseFunctionBody(node, /* allowExpression */ false, /* allowMissingBody */ type === "ClassMethod"); |
There was a problem hiding this comment.
I think we could pass an object here, like:
maybeParseFunctionBody({ allowExpression: false, allowMissingBody: type === "ClassMethod"});Looks better than comments to me.
src/parser/expression.js
Outdated
| // Strict mode words may be allowed as in `declare namespace N { const static: number; }`. | ||
| // And we have a type checker anyway, so don't bother having the parser do it. | ||
| return; | ||
| } |
There was a problem hiding this comment.
What about a better integration with TypeScript here? Early grammar errors are great for online editor (like Babel's REPL). Babylon has that kind of logic for JavaScript.
There was a problem hiding this comment.
We would have to know of whether we're in a declaration context or not. And knowing that requires knowing the current file extension. export let package: number; is a perfectly legal .d.ts file.
There was a problem hiding this comment.
And knowing that requires knowing the current file extension.
We could also add a "sourceType": "declaration" which treats files as .d.ts
src/parser/expression.js
Outdated
| @@ -786,6 +795,8 @@ export default class ExpressionParser extends LValParser { | |||
| node.callee = this.parseNoCallExpr(); | |||
| const optional = this.eat(tt.questionDot); | |||
|
|
|||
| this.parseNewTypeArguments(node); | |||
There was a problem hiding this comment.
I didn't notice this before: is it possible to implement new type arguments only in the typescript plugin?
Something like
parseNew() {
const node = super.parseNew();
if (/* node is NewExpression */ && !/* node has args parentheses*/ && this.match("<")) {
// parse type arguments
// maybe parse arguments
}
}Anyway, apart from this detail this pr looks good to me! (well, I have to admit I haven't reviwed all of it because I don't know typescript very well 😅 )
There was a problem hiding this comment.
I don't think the AST gives us a way to distinguish between new X and new X(). But I found a different way that works just as well, see the latest commit 102be0e.
|
I have a concern about versioning: https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes makes me think that typescript can have breaking changes. Does this PR make babylon potentially need a major version bump every time a new ts version is released? |
|
Typescript never had syntactic breaking changes. Meaning valid syntax that is supported by one version and disallowed by a newer version. All breaking changes are semantic in nature; either new error checks or new behaviors for the type system. All these are outside the scope of Babylon. There are some changes in the resulting code from tsc but these are not relevant here either. |
|
Thank you 👍 |
src/plugins/typescript.js
Outdated
| // 99% certain this is `new C<T>();`. But may be `new C < T;`, which is also legal. | ||
| const typeParameters = this.tsTryParseAndCatch(this.tsParseTypeArguments.bind(this)); | ||
| if (typeParameters) { | ||
| node.typeParameters = typeParameters; |
There was a problem hiding this comment.
I think you should check that this.match(tt.parenL), otherwise new Foo<T> will be allowed
|
Congrats, @andy-ms! Awesome work 😄 We can keep fine tuning the AST together but it's fantastic to have this merged! |
ghost
deleted the
|
@hzoo Please notify me when this is published. |
|
yep doing it now! |
|
Oh. My. God. <3 |
This is a WIP, so please don't merge yet. The AST spec is likely to change. I am just looking to get comments on the implementation.
For those interested in just the AST spec, just look at the changes to
src/types.js. I am tracking differences with typescript-eslint-parser here.CC @stephen @JamesHenry @DanielRosenwasser
Notes:
It shares a lot in common with the flow plugin, but for now I am just using identical code (and marking it as such). In the future they should probably share.
Test files should really have a
.tsextension, but that would require editingbabel-helper-fixtures. Shall I make a pull request there?