bug: Parse error on const x: import('foo').Bar<Baz>

[gthb]

Did you check existing issues?

• I have read all the tree-sitter docs if it relates to using the parser
• I have searched the existing issues of tree-sitter-typescript

Tree-Sitter CLI Version, if relevant (output of tree-sitter --version)

tree-sitter 0.25.0 (ba19fe31bed96a28aa5a1b9253a716e494ed7a9b)

Describe the bug

A type declaration containing the dynamic import syntax with a type parameter applied fails to parse, though it is valid Typescript.

Steps To Reproduce/Bad Parse Tree

Minimal example:

const foo: import('./bar').Bar<string> = 'baz';

This is valid Typescript, but tree-sitter-typescript produces a parse error:

❯ tree-sitter parse foo.ts                      
(program [0, 0] - [1, 0]
  (lexical_declaration [0, 0] - [0, 30]
    (variable_declarator [0, 6] - [0, 30]
      name: (identifier [0, 6] - [0, 9])
      type: (type_annotation [0, 9] - [0, 30]
        (member_expression [0, 11] - [0, 30]
          object: (call_expression [0, 11] - [0, 26]
            function: (import [0, 11] - [0, 17])
            arguments: (arguments [0, 17] - [0, 26]
              (string [0, 18] - [0, 25]
                (string_fragment [0, 19] - [0, 24]))))
          property: (property_identifier [0, 27] - [0, 30])))))
  (expression_statement [0, 30] - [0, 47]
    (type_assertion [0, 30] - [0, 46]
      (type_arguments [0, 30] - [0, 38]
        (predefined_type [0, 31] - [0, 37]))
      (ERROR [0, 39] - [0, 40])
      (string [0, 41] - [0, 46]
        (string_fragment [0, 42] - [0, 45])))))
foo.ts	Parse:   14.33 ms	    3 bytes/ms	(MISSING ";" [0, 30] - [0, 30])

Expected Behavior/Parse Tree

I expect a parse tree without error nodes.

I'm not familiar enough to say exactly what that valid tree should look like, because I'm not using tree-sitter directly — I'm using it via Difftastic (with git -c diff.external=difft diff), and these parse errors cause Difftastic to fall back to a text-based (not syntax-aware) diff.

Repro

const foo: import('./bar').Bar<string> = 'baz';

[gthb]

See #246 where a parse error involving the import(...) syntax in a type assertion context was fixed — I suppose that fix just overlooked the import(...).Type<TypeParams> case.