Generated type definitions don't declare optional parameters

[lance]

When using the new direct object style API to create a CloudEvent in a TypeScript project, the CloudEvent constructor requires all properties for the event to be provided.

This is what the constructor signature looks like in the generated type definition.

    constructor({ id, source, type, dataContentType, time, subject, dataSchema, schemaURL, dataContentEncoding, data, specversion }?: {
        source: string; 
        type: string;
        id: string; 
        time: string;
        subject: string;
        dataContentType: string;
        dataSchema: string;
        schemaURL: string;
        dataContentEncoding: string;
        specversion: string;
        data: any;
    });

There are two things wrong with this. First of all, it shows the single properties parameter as being optional, and it indicates that each of the individual fields of this properties parameter is required. This does not happen in a pure JavaScript project because the autocompletion feature in VSCode for JS projects that also have type definitions prefers the .js version over the .d.ts version. In a TypeScript project, however, the VSCode autocompleter only considers the .d.ts file.

Until a fix is in place, there may be a work around by adding some TypeScript configuration option. But I'm not sure what that is - don't have enough experience with it yet.

[grant]

This seems like a blocker for projects that use this library using TypeScript and require optional types.
A solution would be to declare a CloudEvent interface with optional fields.
Curious to see the solution.

[lance]

@grant I have been reading and playing around with this for the last hour and was going to come back here and ask if perhaps an interface would fix this. And I find this.

but that obviously uses TypeScript which we can't have.
Curious to see the solution.

For crying out loud, please can't you just be civil for once?

Yes, let's please find the right solution. I have an inelegant quick fix here: #189.

I am surprised that you let us push a 2.0.0 release without noticing this. Did you not try to use the SDK in a TypeScript project before approving #155?

[lance]

I assume an interface would address #184 as well.

[grant]

Yes, sorry, that was a bit impolite, @lance. I've edited the comment.
Still genuinely interested in seeing the technological solution though. I'm still seeing things through the eyes of technical constraints.