Added ability to generate typings for grpc-node service files

[foxdavidj]

This PR adds the ability for users to output typings for the service files generated by protoc for node. Let me know if you have any questions or concerns about adding this to the library :)

Note: The addition of the two deps is strictly for the types they provide.

[anisimovsergey]

Exactly what I need!

[jonny-improbable]

Thanks for contributing @OBTo; this looks great! Before I can merge this please could you follow up with the following changes:

1. Pull your new code out into a separate file, let's keep service generation separate
2. Add test coverage to ensure that the generated .d.ts are valid and don't regress with future changes (we have examples of this already for the grpc-web service definitions).

[MOZGIII]

Just FYI, this seem to require the js files to be generated separately by the grpc-tools package.
I'm using @OBTo's fork for now, looking forward to the merge.

[jonahbron]

Not totally sure, but this might be rendered moot by #40

[Junkern]

What is the status of this PR?

In contrary to @jonahbron, I don't think it is rendered moot by #40. By using service=trueI now (0.6.0 version) indeed get types and stubs for my RPC calls, but the files have an import {grpc} from "grpc-web-client". I am using the vanilla grpc dependency without any additional libraries (as it already has node.js support).

The readme has a Generating gRPC Service Stubs for use with grpc-web entry but what about `Generating gRPC Service Stubs for use with vanilla-grpc``

Everything is working so far except that I cannot use the created service.* files due to not having the grpc-web-client dependency in my project. I could add a post-build step to remove the code I don't need, but I'd rather not go down that rabbit hole.

[jonnyreeves]

@Junkern is correct, #40 generates service stubs for grpc-web, not google's own NodeJS grpc library.

This diff is going to require quite a lot of effort to get it rebased following a couple of extensive refactors (in particular #40 and #51) however I do see the benefit of having ts-protoc-gen output these typescript definitions.

I'm pretty busy at the moment and don't have a lot of time to contribute, is there anyone reading that would be in a position to pick this PR up, please?

[foxdavidj]

Unfortunately, I wont have time to make the necessary changes (added tests and some refactoring) anytime soon. Quite swamped atm.

[Junkern]

I could do it, as I want to have this anyway ;) Should I rework the current PR or start a new one (clean state....)? @jonnyreeves

[jonnyreeves]

Awesome, thanks for volunteering. Clean state referencing the work achieved here may be quicker IMHO. Note you may wish to wait for #69 to land first.

…

On Wed, 23 May 2018, 08:41 Martin, ***@***.***> wrote: I could do it, as I want to have this anyway ;) Should I rework the current PR or start a new one (clean state....)? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMN-f9aT7CN5W29SSNAsBNbIwlYxEV4ks5t1RK3gaJpZM4Sd9ER> .

[Junkern]

FIY: #69 has landed, so I will start working on this

[jonnyreeves]

Closing in favour of #75