TypeScript type generation wrong when using multiple files

I’m currently migrating my GRPC service declarations from JS to Typescript and noticed that the code generation is wrong when referencing messages/types from other files.

Given the code below, the following MyServiceServiceClientPb.ts is generated:

...
  methodInfoaddOne = new grpcWeb.AbstractClientBase.MethodInfo(
    MyMessagesFile_pbInteger,
    (request: MyMessagesFile_pbInteger) => {
      return request.serializeBinary();
    },
    MyMessagesFile_pbInteger.deserializeBinary
  );
...

Note the correct type is MyMessagesFile_pb.Integer (the dot is missing)!

This is printed in grpc_generator.cc:713.

---

Using libprotoc 3.11.1 and grpc-web 1.0.7

MyServiceFile.proto

syntax = "proto3";
import "MyMessagesFile.proto";

service MyService {
  rpc addOne(Integer) returns (Integer);
}

MyMessagesFile.proto

message Integer {
  int32 number = 1;
}

package.json

{
  ...
  "scripts": {
    ...
    "grpc-generate": "mkdir -p src/proto && protoc -I=/path/to/proto/folder /path/to/proto/folder/*.proto --js_out=import_style=commonjs:src/proto --grpc-web_out=import_style=typescript,mode=grpcwebtext:src/proto && for f in src/proto/*.js; do sed -i '1s;^;/* eslint-disable */;' $f; done",
    "grpc-generate-macos": "mkdir -p src/proto && protoc -I=/path/to/proto/folder /path/to/proto/folder/*.proto --js_out=import_style=commonjs:src/proto --grpc-web_out=import_style=typescript,mode=grpcwebtext:src/proto && for f in src/proto/*.js; do sed -i '' '1s;^;/* eslint-disable */;' $f; done",
    ...
  }
  ...
}

[Jdban]

Affecting me too… can you share your sed expression @Jdban?

Sure, it’s not very generic though. It’s just doing an explicit find/replace on the string in all the .ts files.

in our bash script:

# Handles this annoying bug: https://github.com/grpc/grpc-web/issues/693
ORIGINAL=shared_pbFilterRequest
REPLACEMENT=shared_pb.FilterRequest
grep -l -E "$ORIGINAL" **/*.ts  | xargs sed -i.bak "s#$ORIGINAL#$REPLACEMENT#g"
rm -rf js/*.bak   # Our files are in a js folder

[rieshy]

Unfortunately the fix does not seem to cover the “enum” entries defined in the imported proto. The “.” is still missing for them using release 1.2.1