-
Notifications
You must be signed in to change notification settings - Fork 172
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
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=true
flag 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 RFC: The future of this package #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 protoc-gen-improbable-eng-grpc-web Hello World 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=true
option has been replaced withservice=grpc-web
, following the suggestion in Ability to generate typings for grpc-node service files #75 (comment).service=grpc-node
option can be used to generate grpc-node service types, writing a_grpc_pb.d.ts
file for each_grpc_pb.js
file generated by the protoc-gen-grpc plugin.Verification
To facilitate testing of the
service
options and the newservice=grpc-node
option in particular, the generate.sh script has been modified following #75 (comment):examples/generated
contains the output when theservice
option is not usedexamples/generated-grpc-web
contains the output for theservice=grpc-web
optionexamples/generated-grpc-node
contains the output for theservice=grpc-node
optionThe generate.sh script uses grpc-tools to generate
_grpc_pb.js
implementation files to help test that the generated_grpc_pb.d.ts
files are consistent with them.