Skip to content
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

proto-loader-gen-types Typename templates #2183

Merged
merged 2 commits into from Sep 21, 2022
Merged

Conversation

install
Copy link
Contributor

@install install commented Aug 5, 2022

  • Allow for customizing the naming pattern for both restricted and permissive types

Enums and filenames are left untouched

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Aug 5, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

  • ✅ login: install / name: austin (49b7c5c)

@murgatroid99
Copy link
Member

Can you expand some more on what your use case is for this, and also why you excluded enums?

@install
Copy link
Contributor Author

install commented Aug 19, 2022

@murgatroid99
I've found that for the majority of my use cases I'm consuming the __Output types, so it'd be nice if the consumer can determine the naming format for inputs vs outputs.

The enum is a special case because it's both a type and a value. Parent messages seem to reference the enum directly.

export interface TestMessage {
  'enum'?: (test_v1_Enum | keyof typeof test_v1_Enum);
}

export interface TestMessage__Output {
  'enum': (keyof typeof test_v1_Enum);
}

It might be worth treating enums like messages in that we create both an input and an output version, and the input/output parent message would point to the corresponding one. I wanted to leave that for a different PR for now.

@install
Copy link
Contributor Author

install commented Sep 6, 2022

Hey @murgatroid99 have you had a chance to look at this? I'm open to any feedback and suggestions :) thanks

Copy link
Member

@murgatroid99 murgatroid99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not confident that inputName is called everywhere it is needed. Since the default behavior is to leave the string unchanged, the current tests will not catch if it is omitted anywhere. Can you add a test with a different --inputTemplate option?

Please also create a PR to add information about these new options to this file.

packages/proto-loader/bin/proto-loader-gen-types.ts Outdated Show resolved Hide resolved
packages/proto-loader/bin/proto-loader-gen-types.ts Outdated Show resolved Hide resolved
- Allow for customizing the naming pattern for both restricted and permissive types
@install
Copy link
Contributor Author

install commented Sep 7, 2022

@murgatroid99 Thanks for the feedback! I've addressed your comments and updated the golden tests to use the new flags.
Here's the corresponding proposal PR: grpc/proposal#326

@snarky-puppy
Copy link

FYI - prefixing interfaces with "I" conflicts with Hungarian notation commonly misused in other parts of the TS ecosystem. Suggest prefixing with "In"/"Out" rather than "I/O"

@install
Copy link
Contributor Author

install commented Sep 19, 2022

FYI - prefixing interfaces with "I" conflicts with Hungarian notation commonly misused in other parts of the TS ecosystem. Suggest prefixing with "In"/"Out" rather than "I/O"

It's just an example. This won't actually change any of the generated type names by default. Nevertheless if @murgatroid99 prefers different values for the golden test I can change it.

@murgatroid99
Copy link
Member

It doesn't matter to me. That test is mainly there to verify the consistency of the generator output.

@install
Copy link
Contributor Author

install commented Sep 21, 2022

@murgatroid99 How can I help push this forward?

@murgatroid99
Copy link
Member

Sorry about the delay here.

@murgatroid99 murgatroid99 merged commit 04b14eb into grpc:master Sep 21, 2022
@murgatroid99
Copy link
Member

This is out in version 0.7.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants