fix: improve ts-only declaration parsing #17491
Conversation
JLHwung
added
PR: Bug Fix 🐛
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/59875 |
|
commit: |
| } | ||
| case "global": | ||
| // `global { }` (with no `declare`) may appear inside an ambient module declaration. | ||
| // Would like to use tsParseAmbientExternalModuleDeclaration here, but already ran past "global". |
There was a problem hiding this comment.
This todo item is also resolved now that the global module parsing has been moved to parseStatementContent when global is not yet consumed.
| if (this.isContextual(tt._interface)) { | ||
| const result = this.tsParseInterfaceDeclaration(this.startNode()); | ||
| if (result) return result; | ||
| if (!this.state.containsEsc) { |
There was a problem hiding this comment.
This check is redundant for tt._const, however it is more convenient to group tt._const handling with other keyword-likes.
| case tt._abstract: | ||
| case tt._declare: { | ||
| if ( | ||
| this.nextTokenIsIdentifierAndNotTSRelationalOperatorOnSameLine() |
There was a problem hiding this comment.
There is a finite number of keyword tokens allowed to follow abstract / declare. In reality most input source is valid, to simplify the lookahead logic and exit early for valid code, we check all identifiers except in, instanceof, as and satisifies: If a declaration can not be parsed, it must be an invalid production in both JS and TS.
| const node = this.startNode<N.TsTypeAliasDeclaration>(); | ||
| this.next(); // eat 'type' | ||
| const result = this.tsParseTypeAliasDeclaration(node); | ||
| if (result) return result; |
There was a problem hiding this comment.
This check is redundant, tsParseTypeAliasDeclaration always returns a node.
Handle TS declaration parsing in parseStatementContent such that we can align to the tsc behaviour when parsing `type as =` or `module as {}`. In both cases tsc treats `as` as an identifier name, but previously Babel parser treated it as rational operator because the ts-only declaration parsing was delayed after a JS expression is formed.
github-actions
bot
added
the
outdated
4 participants
Handle TS declaration parsing in
parseStatementContentsuch that we can align to the tsc behaviour when parsingtype as =ormodule as {}. In both cases tsc treatsasas an identifier name, but previously Babel parser treated it as rational operator because the ts-only declaration parsing was delayed after a JS expression is formed.This PR also fixes a similar case:
module as {}should be interpreted as aTSModuleDeclarationrather than aTSAsExpression.