API Declaration loses type safety

Hi,

I just started using this library, and I’m impressed by the performance! However, there were a few issues that I’m struggling with when it comes to typescript type safety. For example, considering this API:

https://github.com/SAP/chevrotain/blob/5c026d34bbe8723d08cb1eb63ddedd710737cb99/packages/chevrotain/api.d.ts#L894-L898

T | any to the compiler is just any, which means that all rules now return any instead of the intended T. This makes it impossible to write the rule class in a type safe manner. Which means that for an example grammar:

export class MyParser extends chevrotain.Parser {
  public constructor() {
    super(MyTokens, {
      recoveryEnabled: true,
      outputCst: false,
    });

    this.performSelfAnalysis();
  }

  public file = this.RULE('file', () => {
    const statements = Array<BaseStatementNode>();
    this.MANY(() => {
      statements.push(this.SUBRULE(this.statement));
    });
    return new FileNode(statements);
  });

  public statement = this.RULE('statement', () => {
    // TODO: get members
    return new IfStatementNode(...members);
  });
}

• file is a rule that returns any instead of FileNode.
• statement is a rule that returns any instead of IfStatementNode.
• SUBRULE has the same problem since it relies on the argument type.
• Most other production helpers are affected as well since type inference is broken.

Is this an intentional design decision? or is it just a bug with the type definition? there might be other APIs that are defined in this manner as well.

[bd82]

I will look into this. Please open a new issue (copy paste your latest comment).

[OmarTawfik]

@bd82 another breaking change I found today: OPTION’s return type should really be T | undefined instead of T.