-
Couldn't load subscription status.
- Fork 171
Add support for generating grpc-node service types #193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for generating grpc-node service types #193
Conversation
1f95c2c to
c66fcde
Compare
c66fcde to
ee6a3da
Compare
09fc784 to
a6fdf5d
Compare
|
|
||
| export const SimpleServiceService: ISimpleServiceService; | ||
|
|
||
| export class SimpleServiceClient extends grpc.Client { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's an example of one of the generated grpc-node service types
| "lodash": "^4.17.5", | ||
| "lodash.isequal": "^4.5.0", | ||
| "minimist": "^1.2.0", | ||
| "mocha": "^5.2.0", | ||
| "mocha-spec-json-output-reporter": "^1.1.6", | ||
| "source-map-support": "^0.4.18", | ||
| "ts-node": "^5.0.1", | ||
| "ts-node": "^8.3.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I was working on this, it seemed that ts-node 5.0.1 wasn't catching type errors in test/integration/service/grpcnode.ts - I tried updating to the latest 8.3.0 and then it did catch them and would cause npm run test to fail, as expected.
| @@ -46,13 +46,15 @@ | |||
| "babel": "^6.5.2", | |||
| "browser-headers": "^0.4.1", | |||
| "chai": "^3.5.0", | |||
| "grpc": "^1.22.2", | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this package ok here in "devDependencies" even though it's imported in the generated _grpc_pb.d.ts files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep should be fine, I see you are only consuming the grpc package in your tests (hence a dev dependency) so shouldn't cause an issue for consumers.
| } | ||
| } | ||
|
|
||
| export class GrpcServiceDescriptor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is unchanged code extracted from grpcweb.ts - except for renaming this class from GrpcWebServiceDescriptor to GrpcServiceDescriptor since it wasn't necessarily specific to grpc-web.
test/mocha-run-suite.sh
Outdated
| @@ -19,7 +19,7 @@ fi | |||
| mocha \ | |||
| --reporter mocha-spec-json-output-reporter \ | |||
| --reporter-options "fileName=./test/mocha-report.json" \ | |||
| --require ts-node/register/type-check \ | |||
| --require ts-node/register \ | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type-check is the default behavior in the newer ts-node
|
Hi @jonny-improbable 👋 I wondered if this is still a feature you think is worth pursuing? If so, I think this PR is potentially ready for a review. Whenever you have a chance to take a look, if there's anything I can do to help make it easier to review, I will be happy to do that. (I wondered about breaking off an initial PR that did nothing but adding that Anyway, sorry to @ ping you - I'll look forward to any next steps to take with this PR, and of course will understand if this just isn't a path for this project to go down. Cheers! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I like your approach; and from experience I can imagine this was a lot of work!
Some thoughts in no particular order.
-
Migration Path; I feel that it's important we provide a migration path for users; if we land this change as is, ts-protoc-gen with the
service=trueflag will no longer emit gprc-web client stubs which may be confusing for consumers. Can I suggest you add some logic to detect the usage ofservice=true, and emit a prominent message that this functionality will be deprecated and the consumer must change their usage ofprotoc. -
Ownership; are you able to commit to triaging issues that may arise from people using this code? I am not a consumer of 'node grpc' myself so will need help here.
-
Placement; see #145, I would actually prefer if this package went away however as you can see I haven't made much progress on this issue (and it got automatically closed, sorry about that!). Note that https://github.com/agreatfool/grpc_tools_node_protoc_ts appears to already provide gprc-node service creation; perhaps that package provides all the functionality required in which case encouraging users to migrate to https://github.com/agreatfool/grpc_tools_node_protoc_ts may be the better option once improbable-eng/grpc-web#368 is merged...
Please let me know your thoughts on the above, and sorry for the slow turn around.
| @@ -46,13 +46,15 @@ | |||
| "babel": "^6.5.2", | |||
| "browser-headers": "^0.4.1", | |||
| "chai": "^3.5.0", | |||
| "grpc": "^1.22.2", | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep should be fine, I see you are only consuming the grpc package in your tests (hence a dev dependency) so shouldn't cause an issue for consumers.
src/index.ts
Outdated
| generateGrpcWebService(outputFileName, fileNameToDescriptor[fileName], exportMap) | ||
| .forEach(file => codeGenResponse.addFile(file)); | ||
| } | ||
| if (generateGrpcNodeServices) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be else if to reflect the fact that it's not possible to emit both grpc-web and grpc-node services at the same time.
| @@ -44,31 +44,40 @@ describe("service/grpc-web", () => { | |||
| assert.strictEqual(SimpleService.DoClientStream.responseType, Empty); | |||
| }); | |||
|
|
|||
| it("should contain the expected DoClientStream method", () => { | |||
| it("should contain the expected DoBidiStream method", () => { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙏
|
Thanks Jonny!
I ended up going down this path because:
Do you think there's a case for adding this functionality to ts-protoc-gen, for however much current users of the package may get out of it, with the understanding that you would still be pursuing #145 and these grpc-node services wouldn't be part of the plans going forward? If so, I'd reiterate my commitment to owning any issues related to this code. But if not, I certainly understand, and could look at contributing and migrating to that other project instead. (Thanks for the pointer to that ts-morph library, looks cool!) |
|
Morning @esilkensen, Thanks for answers my questions above; it looks like we are all set! Sorry to be a pain, but I've just landed #195 which has caused a number of conflicts, in particular around the way the example protos are generated. Please could you resolve these and then we will be good to merge. |
|
Sounds good, thanks so much @jonny-improbable, I've just resolved the conflicts and will watch to make sure CI passes. (Then head to bed, it is early morning for me 😴) |
|
Hi @jonny-improbable, I just wanted to check back in on this PR, to see if you were still thinking of merging it -- or if there are any additional changes I could make? Thanks again! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do this.
|
Nice! What do you think about versioning? Will this eventually make it into a 0.10.1 release? (I'll pull from |
|
0.x versioning is a little hectic, I'll just bump this out at 0.11 as it
contains a major new feature.
…On Fri, 30 Aug 2019 at 08:24, Erik Silkensen ***@***.***> wrote:
Nice!
What do you think about versioning? Will this eventually make it into a
0.10.1 release?
(I'll pull from ***@***.*** in the meantime)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#193?email_source=notifications&email_token=ADMBV4L5VALSDHADYKUUQJ3QHDDMXA5CNFSM4IJIA3VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5QZZ6I#issuecomment-526490873>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADMBV4IRWU7LZBKSRFDNDRDQHDDMXANCNFSM4IJIA3VA>
.
|
Changes
This PR adds support for generating grpc-node service types (see #75, #42, #27):
service=trueoption has been replaced withservice=grpc-web, following the suggestion in Ability to generate typings for grpc-node service files #75 (comment).service=grpc-nodeoption can be used to generate grpc-node service types, writing a_grpc_pb.d.tsfile for each_grpc_pb.jsfile generated by the protoc-gen-grpc plugin.Verification
To facilitate testing of the
serviceoptions and the newservice=grpc-nodeoption in particular, the generate.sh script has been modified following #75 (comment):examples/generatedcontains the output when theserviceoption is not usedexamples/generated-grpc-webcontains the output for theservice=grpc-weboptionexamples/generated-grpc-nodecontains the output for theservice=grpc-nodeoptionThe generate.sh script uses grpc-tools to generate
_grpc_pb.jsimplementation files to help test that the generated_grpc_pb.d.tsfiles are consistent with them.