Update typescript dependency to v5.9.3 results in test failures in interop_gen_test.dart

[srujzs]

Upgrading the NPM dependency to v5.9.3 results in a few failures spots:

parameters seems to be sometimes null:

web/web_generator/lib/src/js/typescript.types.dart

Line 457 in 552acc1

external TSNodeArray<TSParameterDeclaration> get parameters;

.

web/web_generator/lib/src/interop_gen/transform/transformer.dart

Line 1523 in 552acc1

final parameters = funType.parameters.toDart

throws because of that.

---

members also seems to be sometimes null:

web/web_generator/lib/src/js/typescript.types.dart

Line 484 in 552acc1

external TSNodeArray<T> get members;

.

web/web_generator/lib/src/interop_gen/transform/transformer.dart

Line 498 in 552acc1

for (final member in typeDecl.members.toDart) {

throws because of that.

There are likely other failure spots after getting past those issues.

The first is fixable, but in the second, the type decl seems to point to a function rather than an interface, so it's not obvious what the solution is there. It's also not clear under what situations we should expect a non-nullable vs a nullable. For now, I'll pin the dependency to the current version, v5.8.3.

cc @nikeokoronkwo

[nikeokoronkwo]

parameters seems to be sometimes null:

That should not be the case, though, because parameters should be non-null:

// Extracted from: typescript.d.ts for "typescript@5.9.3"
declare namespace ts {
    // ...
    interface SignatureDeclarationBase extends NamedDeclaration, JSDocContainer {
        readonly kind: SignatureDeclaration["kind"];
        readonly name?: PropertyName;
        readonly typeParameters?: NodeArray<TypeParameterDeclaration> | undefined;
        readonly parameters: NodeArray<ParameterDeclaration>;
        readonly type?: TypeNode | undefined;
    }
    // ...
}

There might be a different problem causing the parameters to be null. Is there a specific example you can show so that I could possibly take a look?

members also seems to be sometimes null:

...

The first is fixable, but in the second, the type decl seems to point to a function rather than an interface, so it's not obvious what the solution is there...

This should also not be the case:

declare namespace ts {
    // ...
    interface ClassLikeDeclarationBase extends NamedDeclaration, JSDocContainer {
        readonly kind: SyntaxKind.ClassDeclaration | SyntaxKind.ClassExpression;
        readonly name?: Identifier;
        readonly typeParameters?: NodeArray<TypeParameterDeclaration>;
        readonly heritageClauses?: NodeArray<HeritageClause>;
        readonly members: NodeArray<ClassElement>;
    }
    interface ClassDeclaration extends ClassLikeDeclarationBase, DeclarationStatement {
        readonly kind: SyntaxKind.ClassDeclaration;
        readonly modifiers?: NodeArray<ModifierLike>;
        /** May be undefined in `export default class { ... }`. */
        readonly name?: Identifier;
    }

    // ...
    interface InterfaceDeclaration extends DeclarationStatement, JSDocContainer {
        readonly kind: SyntaxKind.InterfaceDeclaration;
        readonly modifiers?: NodeArray<ModifierLike>;
        readonly name: Identifier;
        readonly typeParameters?: NodeArray<TypeParameterDeclaration>;
        readonly heritageClauses?: NodeArray<HeritageClause>;
        readonly members: NodeArray<TypeElement>;
    }
    // ...
}

---

The problem we're having is not because the declaration types are wrong, but because the declaration kinds are wrong. The enum values for the declaration kinds were shifted in TypeScript 5.9 (which was part of the reason why I hadn't updated the version earlier).

declare namespace ts {
    enum SyntaxKind {
    // ...
    FunctionDeclaration = 263, // was 262
    ClassDeclaration = 264, // was 263
    InterfaceDeclaration = 265, // was 264
    // ...
    }
}

It should be a minor fix, therefore.

[nikeokoronkwo]

@srujzs Should this go in a separate PR, or would you mind if I add it to #482

[srujzs]

Is there a specific example you can show so that I could possibly take a look?

If you update the TS version and run interop_gen_test.dart you should see the failures immediately.

The problem we're having is not because the declaration types are wrong, but because the declaration kinds are wrong.

Ah okay, this explains the mismatch in members to their processed types in the transformer. Thanks for the investigation!

Should this go in a separate PR, or would you mind if I add it to #482

Let's put it in a separate PR where we upgrade the TS version as well. #482 has some other issues I need to brainstorm more about before I can land.