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?