njpatel/grpcc

Unable to find package when enum is present at root of package.

Disturbing opened this issue · 6 comments

I've added an enum at the root of the package of a proto file and the grpc options for packages shows as follows:

https://puu.sh/xyr8B/806119c65a.png

If you wrap the enum in a message, it resolves the problem and shows the proper package for the API.

https://puu.sh/xyr9N/3c5858b4df.png

Please support the following example proto file to ensure that you can find a package even with enum at the root

`
package kintohub.authblock.generated;

service AuthBlock {
rpc Login(LoginRequest) returns (LoginResponse) {
option (google.api.http) = {
post: "/auth/login"
body: "*"
};
}

rpc Register(CreateRequest) returns (CreateResponse) {
	option (google.api.http) = {
		post: "/auth/register"
		body: "*"
	};
}

rpc ValidateEmail(ValidateEmailRequest) returns (ValidateEmailResponse) {
	option (google.api.http).get = "/auth/validate";
}

//	rpc ForgotPassword(ForgotPasswordRequest) returns (ForgotPasswordResponse) {
//		option (google.api.http) = {
//			post: "/auth/forgotpassword"
//			body: "*"
//		};
//	}
//
//	rpc ResetPassword(ResetPasswordRequest) returns (ResetPasswordResponse) {
//		option (google.api.http) = {
//			post: "/auth/resetpassword"
//			body: "*"
//		};
//	}

}

message SessionData {
enum SessionRole {
GUEST = 0;
AUTHED_USER = 1;
};
}

`

Environment: Windows 10 64bit, grpcc version 0.0.8, Protobuf 3.4.0, GRPC 1.4.0

Instead of parsing through the proto file, wouldn't it be easier to add an option to pass in the package name?

Something like...

$ grpcc --proto ./service/myservice.proto --address 127.0.0.1:3466 --package package.name

And yeah, this function is not behaving correctly: https://github.com/njpatel/grpcc/blob/master/lib/index.js#L41

I feel like that approach is quite hacky and convoluted. I'd say we should forget about trying to figure out all the services automatically (unless grpc library has a way to do this nicely) and just let the user enter the package name.

Closing as dupe of #31, should have a release today that fixes this.