improbable-eng / ts-protoc-gen Goto Github PK

This library has maintained TS support which would allow ts-protoc-gen to be slimmed down. Further because we're using static protobuf the minimal dependency is only 6.5k.

In order to improve support for Bazel, we should introduce a rule to allow generation of TS protos idiomatically with Bazel.

The benefits

1. Ability to synchronise generated code for multiple targets
2. Native experience for Bazel users
3. Contribution to the ecosystem of Bazel

How

A ts_proto_library already exists (docs) leverages Protobuf.JS. We can utilize the learnings from there to add a similar rule.
The code should be contributed to rules_typescript for uniformity but we should test against the rule ourselves on our CI.

Notes

Initial research of this shows this should be very doable and can provide better integration with Bazel than Protobuf.JS as we can choose to compile individual protos based on the dependency analysis from Bazel.

If you have a use case for ts-protoc-gen and Bazel, please let us know so we can better cater for it.

Currently, it appears that only server-streaming (and when #66 is complete, client-streaming) methods support cancellation. However, cancellation is also useful for unary request/response methods. I.e. when invoking a series of calls in parallel, or when superseding a previously made call with a more up-to-date call.

Perhaps it's worth supporting a mode where a user can request that the generated code always return ResponseStream<T>, even for unary request/response methods? This would also make the API more consistent.

After calling stream.cancel(), the stream still continue to return data causing console to throw error

Uncaught TypeError: Cannot read property 'data' of null

Maybe an example if there is way to do that? thanks!

Some field names are "reserved" such as public. These field names are prefixed with pb_ by the protoc JS generator. ts-protoc-gen needs to follow these same naming conventions.

If I have the following definition:

message MyMsg
{
   enum MyEnum
   {
      None = 0;
      Manual = 1;
      Auto = 2;
   }
   MyEnum type = 1;
}

It generates the following TypeScript definition:

export namespace MyMsg{
  export type AsObject = {
    type: MyMsg.MyEnum,
  }

  export enum MyEnum {
    None = 0,
    Manual = 1,
    Auto = 2,
  }
}

However at runtime, the runtime object for MyEnum has values that are all uppercase, not what specified in the TypeScript definition. Shouldn't ts-protoc-gen generates the uppercase names to match what is generated?

I've noticed that this plugin is adding "List" to the end of every label for repeated fields on a Message. The logic in the code confirms my observations. Is there a reason for this? I'm finding it to be an annoyance and source of confusion, particularly because "List" is appended even for labels that are already pluralized. In fact, a label named object_list would become ObjectListList.

It'd be nice to at least be able to disable this functionality, although maybe I am missing something and there is a good reason it's set up this way since I am relatively new to grpc and protocol buffers.

The actual proto defs I'm using are more complex than this, but the issue boils down to the state of the following pseudo-protos

a.proto

message A {
    message Embed {
        string msg = 1;
    }
}

b.proto

import 'file_a.proto';
message B {
    message C {
        A.Embed one = 1;
    }
}

The objects generated for C reference Embed directly without prefixing A.Embed

Here is an example of what is currently generated

proto.package.b.B.C.deserializeBinaryFromReader = function(msg, reader) {
  while (reader.nextField()) {
    if (reader.isEndGroup()) {
      break;
    }    
    var field = reader.getFieldNumber();
    switch (field) {
    case 1:
      var value = new a_pb.Embed;
      reader.readMessage(value,a_pb.Embed.deserializeBinaryFromReader);
      msg.setOne(value);
      break;
    default:
      reader.skipField();
      break;
    }    
  }
  return msg; 
};

And what it should look like with A.Embed

proto.package.b.B.C.deserializeBinaryFromReader = function(msg, reader) {
  while (reader.nextField()) {
    if (reader.isEndGroup()) {
      break;
    }    
    var field = reader.getFieldNumber();
    switch (field) {
    case 1:
      var value = new a_pb.A.Embed;
      reader.readMessage(value,a_pb.A.Embed.deserializeBinaryFromReader);
      msg.setOne(value);
      break;
    default:
      reader.skipField();
      break;
    }    
  }
  return msg; 
};

I've currently hacked a solution to sed replace a_pb.Embed w/ a_pb.A.Embed. Happy to PR if pointed in the right direction as well. The generation code can be a bit hard to follow.

First this is awesome. Loving being able to use typescript and grpc on the client.

The toObject function is perfect for being able to get a usable object. But would be great to be able to convert back from an object.

So say i'm using one of these fancy frameworks with two way binding. I do toObject... modify values, and then need to send it back. Of course I can build the message manually. But would be fantastic to be able to run a fromObject(object) and have a message ready to go.

• Create changelog
• Release to NPM

Uncommenting any of the maps in the following file causes an error in the ts plugin:

$ cat bad.proto
syntax = "proto3";

message One {
  //map<string, string> foo = 1;
  //map<int32, int32> bar = 2;
  //map<string, Two> baz = 3;
}

message Two {
}

Command and error output when the foo field is uncommented:

$ protoc --plugin=protoc-gen-ts=./node_modules/.bin/protoc-gen-ts --ts_out=. bad.proto
protoc-gen-ts error: Error: No message export for: One.FooEntry
    at node_modules/ts-protoc-gen/lib/ts/message.js:57:23
    at Array.forEach (native)
    at Object.printMessage (node_modules/ts-protoc-gen/lib/ts/message.js:38:38)
    at node_modules/ts-protoc-gen/lib/ts/fileDescriptorTSD.js:29:33
    at Array.forEach (native)
    at Object.printFileDescriptorTSD (node_modules/ts-protoc-gen/lib/ts/fileDescriptorTSD.js:28:41)
    at node_modules/ts-protoc-gen/lib/ts_index.js:25:53
    at Array.forEach (native)
    at node_modules/ts-protoc-gen/lib/ts_index.js:21:48
    at Socket.<anonymous> (node_modules/ts-protoc-gen/lib/util.js:61:9)

Error is equivalent for any of the other fields.

Adding a package statement to the proto definition fixes the error:

$ cat good.proto 
syntax = "proto3";

package foo;

message One {
  map<string, string> foo = 1;
  map<int32, int32> bar = 2;
  map<string, Two> baz = 3;
}

message Two {
}

Running it succeeds:

$ protoc --plugin=protoc-gen-ts=./node_modules/.bin/protoc-gen-ts --ts_out=. good.proto && echo success
success

... Under node 8. It would appear there is an issue with the JavaScript generated by protoc

Input definition:

syntax = "proto3";
import "google/protobuf/wrappers.proto";

message test 
{
    google.protobuf.StringValue mystring = 1;
}

Causes this at runtime:

  TypeError: c.toArray is not a function

  Function.jspb.Message.setWrapperField (node_modules/google-protobuf/google-protobuf.js:207:86)

The use of sh files, and especially calling the protoc-gen-ts (uses #!/usr/bin/env node to execute), from generate.sh makes it really hard to run the scripts on windows. (e.g. generate.bat). Even when running Cygwin or msys

I've messed around with making cmd proxies and whatnot, as well as detecting the system on windows manually in the sh file, but i'd rather ask: Is building on windows going to be supported?

If not, that's ok. I've spent the evening installing Windows Subsystem for Linux and that seems to have done it. The readme could clarify that this is the way to go.

If yes, what's the approach you'd like to take in order to allow running scripts on windows?
I see three options, but there may be more available:

• Maintain sh scripts that run on windows, and insist that users have bash installed
• Maintain powershell (or cmd) scripts that run on windows.
• use js scripts that run from node to do the work

Once you decide, I'd be happy to make a pr.

How would folks feel about making the callback parameter on the generated service clients optional, and returning a native Promise when it's not provided? I'm happy to send a PR if there's interest.

The embedded message incorrectly generates the import statement.

such as:

inner_data.proto:

syntax = "proto3";
package test;
message innerData{
    string name=1;
}

service_test.proto:

syntax = "proto3";
import "inner_data.proto";
package test;
message RequestMessage{
    innerData data=1;
}
message ResultMessage{
    string data=1;
}
service RequestService {
    rpc GetRequest(RequestMessage) returns (ResultMessage);
}

Generated file:
service_test_pb_service.ts:

// package: test
// file: service_test.proto

import * as service_test_pb from "./service_test_pb";
import * as inner_data_pb from "./inner_data_pb";//<<----Cause TS6133 'declared but never used' error
export class RequestService {
  static serviceName = "test.RequestService";
}
export namespace RequestService {
  export class GetRequest {
    static readonly methodName = "GetRequest";
    static readonly service = RequestService;
    static readonly requestStream = false;
    static readonly responseStream = false;
    static readonly requestType = service_test_pb.RequestMessage;
    static readonly responseType = service_test_pb.ResultMessage;
  }
}

Hi, When I execute the following cmd on window 7 OS with protoc 3.5.1:

protoc --plugin=protoc-gen-ts=protoc-gen-ts.bat --js_out=import_style=commonjs,binary:generated --ts_out=service=true:generated -I ./protos ./protos/helloworld.proto

I got the following error message:

protoc --plugin=protoc-gen-ts=protoc-gen-ts.bat --js_out=import_style=commonjs,binary:generated --ts_out=service=true:generated -I ./protos ./protos/helloworld.proto
--ts_out: protoc-gen-ts: Plugin output is unparseable: \r\nE:\\ig\\sample\\ts-server\\sample\\grpc>../../node_modules/.bin/protoc-gen-ts\r\nz\230\r\n\022helloworld_pb.d.tsz\201\r// package: helloworld\n// file: helloworld.proto\n\nimport * as jspb from \"google-protobuf\";\n\nexport class HelloRequest extends jspb.Message {\n  getName(): string;\n  setName(value: string): void;\n\n  serializeBinary(): Uint8Array;\n  toObject(includeInstance?: boolean): HelloRequest.AsObject;\n  static toObject(includeInstance: boolean, msg: HelloRequest): HelloRequest.AsObject;\n  static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};\n  static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};\n  static serializeBinaryToWriter(message: HelloRequest, writer: jspb.BinaryWriter): void;\n  static deserializeBinary(bytes: Uint8Array): HelloRequest;\n  static deserializeBinaryFromReader(message: HelloRequest, reader: jspb.BinaryReader): HelloRequest;\n}\n\nexport namespace HelloRequest {\n  export type AsObject = {\n    name: string,\n  }\n}\n\nexport class HelloReply extends jspb.Message {\n  getMessage(): string;\n  setMessage(value: string): void;\n\n  serializeBinary(): Uint8Array;\n  toObject(includeInstance?: boolean): HelloReply.AsObject;\n  static toObject(includeInstance: boolean, msg: HelloReply): HelloReply.AsObject;\n  static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};\n  static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};\n  static serializeBinaryToWriter(message: HelloReply, writer: jspb.BinaryWriter): void;\n  static deserializeBinary(bytes: Uint8Array): HelloReply;\n  static
deserializeBinaryFromReader(message: HelloReply, reader: jspb.BinaryReader): HelloReply;\n}\n\nexport namespace HelloReply {\n  export type AsObject = {\n    message: string,\n  }\n}\n\nz\211\004\n\032helloworld_pb_service.d.tsz\352\003// package: helloworld\n// file: helloworld.proto\n\nimport * as helloworld_pb from \"./helloworld_pb\";\n\ntype GreeterSayHello = {\n  readonly methodName: string;\n  readonly service: typeof Greeter;\n  readonly requestStream: false;\n  readonly responseStream: false;\n  readonly requestType: typeof helloworld_pb.HelloRequest;\n  readonly responseType: typeof helloworld_pb.HelloReply;\n};\n\nexport class Greeter {\n  static readonly serviceName: string;\n  static readonly SayHello: GreeterSayHello;\n}\nz\344\003\n\030helloworld_pb_service.jsz\307\003// package: helloworld\n// file: helloworld.proto\n\nvar helloworld_pb = require(\"./helloworld_pb\");\n\nvar Greeter = (function () {\n  function Greeter() {}\n  Greeter.serviceName = \"helloworld.Greeter\";\n  return Greeter;\n}());\n\nGreeter.SayHello = {\n  methodName: \"SayHello\",\n  service: Greeter,\n  requestStream: false,\n  responseStream: false,\n  requestType: helloworld_pb.HelloRequest,\n  responseType: helloworld_pb.HelloReply\n};\n\nexports.Greeter = Greeter;\n\n

the proto file is as following:

// Copyright 2015 gRPC authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

syntax = "proto3";

option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";

package helloworld;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

how can I get the correct ts definition of the service. thanks.

Please consider when service=true to use the js_out path to store the generated service js file instead of using, ts_out one. Alternatively if the previous isn't possible service=path/to/jsout maybe, thanks.

protoc -I=. grpc.proto \
  --js_out=import_style=commonjs,binary:./pkg \
  --plugin=protoc-gen-ts=/Users/gert/node/bin/protoc-gen-ts \
  --ts_out=service=true:./src

A TypeScript compilation error was recently introduced into the codebase but the build did not flag this.

Running the file manually through tsc threw the expected warning:

jonny-mbp:service jonny$ tsc --noEmit ./grpcweb.ts 
grpcweb.ts(287,38): error TS2339: Property 'name' does not exist on type '{ (requestMessage: UnaryRequest, metadata: BrowserHeaders, callback: (error: ServiceError, respon...'.

The ability to leverage Babel 7 & TypeScript cannot happen with the current use of namespaces within the code ts-protoc-gen generates for proto files.

The reason is that the use of namespace is problematic because it requires type information to transpile; a good article that goes over such a problem is this one

Accordingly, there may be value to instead use ES6 modules for the use cases namespace is currently used by ts-protoc-gen to fix this.

Steps to Reproduce

1. Setup Babel7 + Typescript (A quick starterkit that does this is Microsoft's Typescript-Babel7 Starter Kit)
2. Set-up the necessary files to run protoc with ts-protoc-gen options
3. Attempt to compile the Typescript to JS
4. An error should show up saying something along the lines of the following snippet

ERROR in .../foo/bar/baz_pb_service.ts
Module build failed: SyntaxError: /full/path/to/foo/bar/baz_pb_service.ts: Namespaces are not supported.

I just picked up https://github.com/improbable-eng/ts-protoc-gen/pull/42/files , created a new branch on my fork and did npm install and after that a npm run-script build. It failed with

node_modules/@types/text-encoding/index.d.ts(52,13): error TS2403: Subsequent variable declarations must have the same type.  Variable 'TextDecoder' must be of type '{ new (label?: string | undefined, options?: TextDecoderOptions | undefined): TextDecoder; protot...', but here has type 'TextDecoderStatic'.
node_modules/@types/text-encoding/index.d.ts(54,13): error TS2403: Subsequent variable declarations must have the same type.  Variable 'TextEncoder' must be of type '{ new (): TextEncoder; prototype: TextEncoder; }', but here has type 'TextEncoderStatic'.

This dependency is only used in https://github.com/improbable-eng/ts-protoc-gen/blob/master/test/helpers/fakeGrpcTransport.ts#L20

This could be replaced by a const bytes = new Buffer(asString); tests still pass. Were there any special reasons why to use TextEncoder in the first place?

I would be happy to provide a PR for that.

Problem

When writing Go protobufs, importing proto from go src generates wrong imports

Steps to reproduce

import "git.company.com/project/repo/proto/file.proto";

generates the following CommonJS import

var git_company_com_project_repo_proto_file_pb = require('./git.company.com/project/repo/proto/file_pb.js');

which can't be imported. I noticed non of the examples have imports too

Expected

Generate correct imports

The following warning is printed during the publish phase on the Travis CI job - see this build.

npm WARN notice Due to a recent security incident, all user tokens have been invalidated. Please see https://status.npmjs.org/incidents/dn7c1fgrr7ng for more details. To generate a new token, visit https://www.npmjs.com/settings/~/tokens or run "npm login".

Hi,

I would like to contribute to this project with a pull request bringing Flow (https://flow.org/) definitions generation. At fluo.com we use protocol buffers too and we use Flow so it would be definitely be helpful !

I was thinking of adding a ".bin/protoc-gen-flow" plugin that would output flow definitions just like typescript with proper flow options.

How would you welcome such a PR ?

Regards,

Florent

In the grpc node examples folder they generate the contracts between the services, but also the service itself _grpc_pb.js. I notice that you can add service=true to generate the grpc-web bindings, but what about the grpc service definitions?

protoc \
	shared\proto\Api.proto \
	--plugin="protoc-gen-ts=$(PROTOC_GEN_TS_PATH)"make \
    	--js_out="import_style=commonjs,binary:$(protoJavascriptPath)" \
	--ts_out=".\" 

Whatever path I use in ts_out (" ./", ".", :$(protoJavascriptPath), no path at all, empty path, "." , with or without quotes), if I use Powershell or a makefile(CMD): I receive the following error:
--ts_out: protoc-gen-ts: The system cannot find the path specified.

Windows x86-64, libprotoc 3.6.1,

Javascript, php outputs just work fine.

Hey great project and really happy for the bazel support.

I was using the bazel custom rule to generate ts output for my protos but one of them has a dependency on the google protobuf timestamp proto. I imported it through my workspace with the name @com_google_protobuf, and they export proto_libraries for each of the well_known_protos (including timestamp). This is the proto library I pass to the custom rule:

proto_library(
    name = "public_proto",
    srcs = [
        "entities.proto",
    ],
    deps = [
      "@com_google_protobuf//:timestamp_proto",
    ]
)

The generated files look correct, but at the top is an import:

var google_protobuf_timestamp_pb = require('google-protobuf/google/protobuf/timestamp_pb.js');

The problem is the custom rule never generates this file (probably because its a dep, not a source?).
It seems that either the custom rule should generate the file or, if it's only generating srcs, then does my project need to copy the google-protobuf protos in?

I'm trying to use this library on node.js to talk to a gRPC server. In my proto file I have

rpc WatchMetric(stream MetricSubscriptionRequest) returns (stream Event) {}

However, this results in the following code being generated:

example_pb_service.js

Watcher.prototype.watchMetric = function watchMetric() {
  throw new Error("Client streaming is not currently supported");
}

example_pb_service.d.ts

watchMetric(): void;

Since v0.6.0, grpc-web provides an experimental websocket transport which should allow client-side and bidi streaming.

There's an issue with the TS generated for OneOfs that are camelcased. Both the Case Enum type and the Case enum accessor have the wrong casing.

The following message:

message MyMessage{
    oneof thisIsAField{
        int32 anInt = 1;
        string theString = 2;
    }
}

This produces the following TS code:

export namespace MyMessage {
  export type AsObject = {
    anint: number,
    thestring: string,
  }

  export enum ThisIsAFieldCase {
    THISISAFIELD_NOT_SET = 0,
    ANINT = 1,
    THESTRING = 2,
  }
}

And the following JS code:

/**
 * @enum {number}
 */
proto.MyMessage.ThisisafieldCase = {
  THISISAFIELD_NOT_SET: 0,
  ANINT: 1,
  THESTRING: 2
};

As far as I can tell, there is a general bug with the way camelcase fields are handled in pbjs, but it sees like ts was always using the same bug (and was therefore compatible). This is not the case with OneOfs

As a workaround, you can either cast to Any, or you can use one word oneof fields.

I am trying out grpc-web and grpc-proxy. I am getting error when I try to compile proto to ts.

Error: ts_out: protoc-gen-ts: 1% is not a valid Win32 application.

Thank you for your help in advance.

Enum definition doesn't work and protoc-gen-ts crashes:

protoc-gen-ts error: Error: No enum export for: ExampleType
    at /usr/lib/node_modules/ts-protoc-gen/lib/ts/message.js:85:23
    at Array.forEach (native)
    at Object.printMessage (/usr/lib/node_modules/ts-protoc-gen/lib/ts/message.js:38:38)
    at /usr/lib/node_modules/ts-protoc-gen/lib/ts/fileDescriptorTSD.js:29:33
    at Array.forEach (native)
    at Object.printFileDescriptorTSD (/usr/lib/node_modules/ts-protoc-gen/lib/ts/fileDescriptorTSD.js:28:41)
    at /usr/lib/node_modules/ts-protoc-gen/lib/ts_index.js:25:53
    at Array.forEach (native)
    at /usr/lib/node_modules/ts-protoc-gen/lib/ts_index.js:21:48
    at Socket.<anonymous> (/usr/lib/node_modules/ts-protoc-gen/lib/util.js:61:9)

--ts_out: protoc-gen-ts: Plugin failed with status code 1.

with this example:

enum ExampleType {
    TYPE_A = 0;
    TYPE_B = 1;
}

message ExampleMessage {
    ExampleType type = 1;
    string name = 2;
}

I've tried to add enum to the inside of the message:

message ExampleMessage {
    enum ExampleType {
        TYPE_A = 0;
        TYPE_B = 1;
    }
    ExampleType type = 1;
    string name = 2;
}

and compilations succeeds. Unfortunately this isn't solution for me because I need to add enum type to multiple messages.

After running protc with the plugin it all works but there are some extensions in the declaration file that are referencing members that are not exported by google-protobuf.

I have been able to get around this by just deleting these extensions (as i do not need them) but im trying to figure out if this is a bug or if i'm just doing something wrong. since i have not seen anyone else with this issue.

below is one of the direct errors i am getting and sorry in advance i have experience in application development but i am rather new to web development.

Namespace ''google-protobuf'' has no exported member 'Message'

Currently we've to use grpc.unary or grpc.invoke for making any kind of call. While that'd make sense to do if we've to handle headers and trailers for all calls, there are many situations where the rpc semantics are much simpler. Having stub methods to call will provide uniformity with the rpc interfaces exposed in other languages, and will also make development a bit more convenient.

I propose to have stub methods for unary-unary and unary-streaming calls, such that the stubs can be used with the nice async-await syntax including the for-await loop for unary-streaming calls.

Hai!

I've generated a simple service stub and I'm attempting to test my client with a very simple script. In the client.get method, I'm getting the following stack trace.

Is this a result of the request not being made from a browser? Is there an API I can hook into which lets me set HTTP headers manually?

I'd like to start pulling in the package similar to how rules_typescript does - which is by including all of the pertinent bazel files in the npm package, and then in your workspace using a local_repository. Not only will this make installing easier by following a convention, but it also cleans up some dependency version snafus.

Some changes to achieve this:

• Include the defs.bzl file in the npm package (I could use some direction on this one).
• Build the protoc plugin binary within bazel differently. It currently relies on the src directory which isn't part of the npm package. Can investigate just pulling in the binary, or building using the lib directory.
• Update readme.
• Test to compare bazel's binary with the non-bazel one.

I tried this on ubuntu :

_solo@solo-Aspire-5740:~/WebstormProjects/GRPCCLient/GRPCTS$ ./protoc --plugin=protoc-gen-ts= ./node_modules/.bin/protoc-gen-ts --js_out=import_style=commonjs,binary:generated --ts_out=service=true:generated -I ./proto ./proto/a.proto

./node_modules/.bin/protoc-gen-ts: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file. Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think)._

If put them in the same folder location :

solo@solo-Aspire-5740:~/WebstormProjects/GRPCCLient/GRPCTS$ ./protoc --plugin=protoc-gen-ts= ./protoc-gen-ts --js_out=import_style=commonjs,binary:generated --ts_out=service=true:generated -I ./ ./a.proto
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax specified for the proto file: protoc-gen-ts. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
protoc-gen-ts:1:1: Expected top-level statement (e.g. "message").

This is what i get on windows :

_C:\AltsLab\alts-grpc\GRPCClientNew\protoc.exe --plugin=protoc-gen-ts=C:\AltsLab\alts-grpc\GRPCClientNew\node_modules.bin\protoc-gen-ts --ts_out=service=true:generated C:\AltsLab\alts-grpc\GRPCClientNew\proto -I C:\AltsLab\alts-grpc\GRPCClientNew\proto C:\AltsLab\alts-grpc\GRPCClientNew\proto\a.proto

C:\AltsLab\alts-grpc\GRPCClientNew\proto: Permission denied_

Can you please help me resolve either one of this ?
Thanks!

I have a enum defined as

enum ProfileTypeETOS { YieldProfile = 1; Profit = 2; }

The generated TypeScript is

export enum ProfileTypeETOS { YIELDPROFILE = 1, PROFIT = 2, }

You will notice that I have lost the CamelCase enums, is there a way to preserve the case?

• Edit: I've seen commit bd7f658, can this be optional?

run the following script error:

>protoc --proto_path=proto --plugin=protoc-gen-ts=./node_modules/.bin/protoc-gen-ts.cmd --js_out=import_style=commonjs,binary:client --ts_out=service=true:client proto/*.proto
'.' 不是内部或外部命令，也不是可运行的程序或批处理文件。
--ts_out: protoc-gen-ts: Plugin failed with status code 1.

but，remove the --ts_out=service=true:client, run successfully.does not support windows?

A question about the examples/generated files.

in #67, @jonnyreeves commited updated the generated files when commiting, resulting in the following change:

https://github.com/improbable-eng/ts-protoc-gen/pull/67/files#diff-6cee6eac2b0bae17197dc838b7af57a2L208

I'm trying to set up development on my local environment, and the most recent version of protoc (3.5.1) is generating js that uses the setProto3*Field methods (e.g. setProto3EnumField)

I asume that perhaps @jonnyreeves' protoc is out of date, or is there a way to generate the js file using the generic setField method?

Besides this more ergonomic client stubs, I suggest chain builder to build Message:

service.Query(Request.newBuilder().setId(1).setName("xxx").build(), ...

like Java simple-rpc: https://grpc.io/docs/tutorials/basic/java.html#simple-rpc-1
Is it possible?

I have a bookService.proto file which imports books.proto and when the JavaScript is generated for bookService.proto it contains var books_pb = require('./books_pb.js');. The addition of the extension is throwing errors in my build.

Only guess after going through the code I can find is https://github.com/improbable-eng/ts-protoc-gen/blob/master/src/js/fileDescriptorJSServices.ts#L30 where it places the depencies at and replaces .proto with _pb but doesn't take off the JavaScript extensions.

Is there any chance there can be an option to pass to the generator and remove the .js on the import/require statements?

Thanks so much for this project!

Typescript warns Expected 0 arguments, but got 1. when I pass arguments for a protobuf message constructor. google-protobuf implementation of protobuf Message accept arguments.

// input.proto
message InputType {
  string name = 1;
  string email = 2;
}

// errors in typescript

new InputType(['my name', 'my email'])

Consider adding a constructor method to the typescript generated definition.

export class User extends jspb.Message {
  constructor(args?: any[]);

  getName(): string;
  setName(value: string): void;

  getEmail(): string;
  setEmail(value: string): void;

  // ... definition
}

message Example {
    int32 FIELD = 1;
}

creates a .d.ts file containing

export class Example extends jspb.Message {
  getFIELD(): number;
  setFIELD(value: number): void;

  // ...
}

but a .js files containing

/**
 * optional int32 FIELD = 1;
 * @return {number}
 */
proto.api.Example.prototype.getField = function() {
  return /** @type {number} */ (jspb.Message.getFieldWithDefault(this, 1, 0));
};

/** @param {number} value */
proto.api.Example.prototype.setField = function(value) {
  jspb.Message.setField(this, 1, value);
};

Note that these function names are not in caps. When calling getFIELD() this will fail silently in Chrome. Instead, ts-protoc-gen should camelcase the getter/setter method names to match js output.

Currently, im working on a project using grpc for frontend and for microservice intercommunication.
I have a protobuf with syntax "proto3" definition and I want to import "google/protobuf/any.proto"
to be used in my message as following

message Row {
repeated google.protobuf.Any column = 1;
}

Backed generation for that file works correctly, but when I try to generate it for the frontend, it fails telling me the following:

google/protobuf/any.proto: File not found.
AnalyticsService.proto: Import "google/protobuf/any.proto" was not found or had errors.
AnalyticsService.proto:41:14: "google.protobuf.Any" is not defined.

my script to generate the protos looks like:

"proto": "../ti-protos/protoc --plugin=protoc-gen-ts=./node_modules/.bin/protoc-gen-ts --js_out=import_style=commonjs,binary:src/_proto --ts_out=service=true:src/_proto -I ../ti-protos/analyticsManager ../ti-protos/analyticsManager/*.proto",

Any ideas?

In order to allow experimentation with new features earlier, we should continuously publish a snapshot of master. We can do this by publish it as a ts-protoc-gen@next version. This should run as part of CI on successful build.

Hi,

I cannot seem to find a way to combine output from multiple proto files to a single d.ts file.
I need that because the messages in all my proto files are in the same namespace.
Thank you.

Hi,

I am not expert in TypeScript or Angular - sorry!
I did generate your nice *.ts.d files - thanks a lot!
But ng complains about two things - unknown properties - I have commented them out,
but there is still error per each message:

Type 'any' is not a constructor function type.

Anything I can do to fix these errors?

Thanks,
Gennady

import * as jspb from "google-protobuf";

export class BooleanValue extends jspb.Message {
hasValue(): boolean;
clearValue(): void;
getValue(): boolean | undefined;
setValue(value: boolean): void;

serializeBinary(): Uint8Array;
toObject(includeInstance?: boolean): BooleanValue.AsObject;
static toObject(includeInstance: boolean, msg: BooleanValue): BooleanValue.AsObject;
// static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};
// static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};
// static serializeBinaryToWriter(message: BooleanValue, writer: jspb.BinaryWriter): void;
static deserializeBinary(bytes: Uint8Array): BooleanValue;
// static deserializeBinaryFromReader(message: BooleanValue, reader: jspb.BinaryReader): BooleanValue;
}

The TypeScript Number type is a floating point number, which means attempting to express the int64 range in numbers will lead to inaccuracies. The protoc compiler therefore uses strings when expressing large numeric types in JSON.

Perhaps something similar should be considered for the TypeScript type translation?

As a feature request, it would be nice if the generated TypeScript definitions included documentation strings copied over from comments in the original protos.

I'm trying to add my service class to grpc.Server but it throws the Method handler for undefined already provided. error. Apparently the path attribute doesn't exist on service classes.