improbable-eng / ts-protoc-gen Goto Github PK
View Code? Open in Web Editor NEWProtocol Buffers Compiler (protoc) plugin for TypeScript and gRPC-Web.
License: Apache License 2.0
Protocol Buffers Compiler (protoc) plugin for TypeScript and gRPC-Web.
License: Apache License 2.0
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".
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?
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.
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:
Once you decide, I'd be happy to make a pr.
A question about the examples/generated
files.
in #67, @jonnyreeves commited updated the generated files when commiting, resulting in the following change:
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?
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.
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.
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.
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?
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?
In order to improve support for Bazel, we should introduce a rule to allow generation of TS protos idiomatically with Bazel.
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.
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.
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.
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?
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.
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.
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!
npm WARN notice [SECURITY] growl has 1 critical vulnerability. Go here for more details: https://nodesecurity.io/advisories?search=growl&version=1.9.2 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] debug has 1 low vulnerability. Go here for more details: https://nodesecurity.io/advisories?search=debug&version=2.6.8 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
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.
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 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!
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 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.
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
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.
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.
protoc
with ts-protoc-gen
optionsERROR in .../foo/bar/baz_pb_service.ts
Module build failed: SyntaxError: /full/path/to/foo/bar/baz_pb_service.ts: Namespaces are not supported.
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?
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
}
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
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.
... 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)
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'
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.
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.
As a feature request, it would be nice if the generated TypeScript definitions included documentation strings copied over from comments in the original protos.
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;
}
}
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?
When writing Go protobufs, importing proto from go src generates wrong imports
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
Generate correct imports
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?
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.
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...'.
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.
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?
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.
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
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.
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?
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:
defs.bzl
file in the npm package (I could use some direction on this one).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.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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.