Proposal to remove JavaScript classes and just generate interfaces

[davidjgoss]

Currently the JavaScript code generated for messages represents each message object as a class, with implicitly public fields and an empty constructor. This requires two dependencies reflect-metadata and class-transformer to make deserialisation work with the parseEnvelope function.

The classes have no methods, and the only thing they do vs just having plain objects is to default missing non-optional properties to '' (in case of strings) or new objects (for classes) which I think is a dubious practise anyway.

I'd propose we just generate TypeScript types/interfaces rather than classes, meaning the schema would carry no code overhead, and no dependencies, and (de)serialisation could just be handled with standard JSON.parse and JSON.stringify as JavaScript users are well accustomed to. As a data point, cucumber-js and our first-party formatters only work with messages as plain objects and never instantiates the classes.

The automatic empty string/object behaviour would go away - it's unclear if anyone is relying on this.

cc @vitalets @badeball as other consumers of this library - any thoughts?

[vitalets]

I like it! In most cases I use cucumber/messages for types.
The only question is about enums - are you going to transform this to type as well?

export declare enum TestStepResultStatus {
    UNKNOWN = "UNKNOWN",
    PASSED = "PASSED",
    SKIPPED = "SKIPPED",
    PENDING = "PENDING",
    UNDEFINED = "UNDEFINED",
    AMBIGUOUS = "AMBIGUOUS",
    FAILED = "FAILED"
}

[davidjgoss]

Ah right, the enums would stay as-is and still generate some code. (I personally tend to favour a string union for enum use cases, but I wouldn't want to change these ones now.)

[badeball]

which I think is a dubious practise anyway.

I agree and fully support this, as I doubt it will have any unintended consequences for myself. I'd much rather like to rely on the type system for ensuring non-null values (eg. using ?? operator) instead of built-in defaulting, but that's me.

The messages library also tends to "linger" in the dependency tree (JS), with old versions and deprecation notices, causing some noise, so I'm happy to see it go away.