"deserializeBinary" do not exist in "typeof Map" about protoc-gen-ts HOT 10 CLOSED

Yes, it is definitely a problem with the typings package. it has to be fixed upstream.

from protoc-gen-ts.

I've the same issue, without an upstream fix your package is unusable, unfortunately. There are also other Map related bugs in the typings package, see #54816.

In the meanwhile, it could make sense to modify your typescript generator so that it casts the Map type to any first. The example above would then look like this:

reader.readMessage(message, () => (pb_1.Map as any).deserializeBinary(message.tag_path, reader, reader.readString, reader.readString));

It's just a workaround, as long as the upstream fix isn't available. And it's safe, because the JavaScript method jspb.Map.deserializeBinary is really available in the google-protobuf package.

This workaround would make it possible to use your (great) package even with Map. What do you think?

from protoc-gen-ts.

By the way, I started a discussion about the missing typings for deserializeBinary: #54824

from protoc-gen-ts.

it makes sense that we introduce a quick fix to enable those who want to use @types/google-protobuf along with google-protobuf. we don’t care about typings as long as they exist in google-protobuf.

a PR is welcome

Context: we didn’t care about matching the typings of google-protobuf as it was hard to use.

from protoc-gen-ts.

Instead of creating a PR for this project that is just a workaround for a bug in @types/google-protobuf, I've decided to create a PR for @types/google-protobuf to fix the root cause. Then this issue here should be fixed, it already works fine wiht my fork of @types/google-protobuf. Let's see, if my PR will be accepted.

from protoc-gen-ts.

Unfortunately, it is a little bit more complicated. I had to fix the PR, so that the CI pipeline succeeds. In the PR for @types/google-protobuf the class Map<K, V> has this static deserializeBinary method now:

class Map<K, V> {
    ...
    static deserializeBinary<K, V>(
        map: Map<K, V>,
        reader: BinaryReader,
        keyReaderFn: (reader: BinaryReader) => K,
        valueReaderFn: ((reader: BinaryReader) => V) | ((reader: BinaryReader, value: V, opt_valueReaderCallback: (value: V, reader: BinaryReader) => any) => any),
        opt_valueReaderCallback?: (value: V, reader: BinaryReader) => any,
        opt_defaultKey?: K,
        opt_defaultValue?: V
  ): void;
}

But now, the generated code by your package fails to compile again. The reason is, that Map.deserializeBinary expects a protobuf Map as first argument, but in your generated code, an ES2015 Map is passed. The Typescript compiler fails now because of the different interfaces of both Map types.

If we use the example from above, the generated code must be changed similar to this proposal in order to compile again:

...
switch (reader.getFieldNumber()) {
    ...
    case 3: {
        // Create a temporary protobuf map
        const pbMap = new pb_1.Map<string, string>([]);

        // deserialize next key/value pair and store it in the protobuf map
        reader.readMessage(message, () => pb_1.Map.deserializeBinary<string, string>(pbMap, reader, reader.readString, reader.readString));

        // apply the new key/value pair in the ES2015 map, it's only one pair.
        pbMap.forEach((value, key) => {
            message.tag_path.set(key, value);
        });

        break;
    }

    default:
        reader.skipField();
}

I'm not sure, if such a change for your typescript plugin would be accepted as PR by you. Maybe I'm also missing something. A comment from you would be appreciated.

from protoc-gen-ts.

You are right. We have to pass the ES6 map as any to make google protobuf happy. Even though Map is enough for pb.Map type package still wanta the same type. So we have to cast map as any then pass it to google-protobuf to make it happy.

A PR with following changes makes sense to me

• Cast map to any whenever we pass it to google-protobuf.

from protoc-gen-ts.

0.4.0 has been released. now it works with @types/google-protobuf again.

from protoc-gen-ts.

My PR for @types/google-protobuf was accepted. It's part of 3.15.4. Now, deserializeBinary is known and we don't need to cast Map to any first. Instead, we should cast the first argument to any now to pass an ES2015 Map where a protobuf Map is expected. Should I create a new PR for this?

from protoc-gen-ts.

That would be so sweet!

Many thanks!!

from protoc-gen-ts.