Generated class definitions don't implement their corresponding interfaces

[Alexendoo]

protobuf.js version: 5f2f177

syntax = "proto3";

package people;

message Person {
  string name = 1;
}

Produces (some fields omitted)

import * as $protobuf from "protobufjs";

/** Namespace people. */
export namespace people {

    /** Properties of a Person. */
    interface IPerson {

        /** Person name */
        name?: string;
    }

    /** Represents a Person. */
    class Person {

        /**
         * Constructs a new Person.
         * @param [properties] Properties to set
         */
        constructor(properties?: people.IPerson);

        /** Person name. */
        public name: string;

        /* ... */
    }
}

Expected class definition:

class Person implements IPerson { /* ... */ }

[dcodeIO]

In this context, IPerson is the definition of a JSON object that can be supplied to the constructor of Person. It's not really an interface the class implements. The interface was named Person$Properties before, might have been a better name for clarity.

[Alexendoo]

It is, however Person does implement IPerson by way of having all the properties available, adding the explicit implements keyword would mean you can pass a Person to Person.encode() without having to resort to using type assertions:

const writer = Person.encode(Person)

instead of

const writer = Person.encode(Person as IPerson)

which does not provide type safety, as you can use as on any type

Alternatively, the signature of encode could be changed to

public static encode(message: messages.ISigned | message.Signed, writer?: $protobuf.Writer): $protobuf.Writer;

[dcodeIO]

Hmm, I didn't have any issues with providing a Person to encode yet, because it still satisfies the interface, even if it doesn't explicitly implement it - is this maybe related to specific compiler options? The difference there is that, on the interface most properties are optional, while on the class these are on the prototype and thus always present.

[Alexendoo]

Ah my apologies I was looking at the wrong thing for the issue, it's that messages with oneofs aren't compatible with their interfaces (dupe of #808)