-
Notifications
You must be signed in to change notification settings - Fork 71
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
Generated message types from .bin vs. runtime DescriptorSet #489
Comments
How would this work though because the data inside the It could be I'm just not following, though, so correct me if I'm wrong. It just seems like the current way of reading in the binary image and creating the registry at runtime is the most intuitive? |
It's the most intuitive for sure but it runs into the issue of runtime Those are absolutely desirable for ergonomics (typings, etc.). What I'd like to see is an option in |
Yeah, with a flat array of message types, though, we have the same issues as with providing top-level exports spelled out here: #455. Handling name clashes across packages would be tough. I don't see us tackling this anytime soon, but this is something you could write a plugin for maybe? |
@fubhy Going to close this but if you have any other concerns/questions, feel free to reopen. |
I've got a use-case where I'm generating code (using
protoc-gen-es
) for a .bin file descriptor. So far so good...However, at runtime I'd also like to use a registry for the same DescriptorSet. To do so, I've currently got the option to either manually
create a registry of all possible message types, or to use the same FileDescriptor again at runtime like so:
The first option works but is annoying and less convenient than it could be imho.
The second option is quite convenient but doesn't work at runtime because now I've basically got two different instances of the same message types. And since it looks like we should prefer
instanceof
instead of aMessageType.is(...)
util, this means that I can't really compare message types with this because the types in that registry are not the same prototypes as those from the generated code.Furthermore, this option only really works in environments where I can easily load the binary into the runtime. But either way it feels weird (for this use-case) to do codegen and runtime injection of that FileDescriptor instead of just generating that beforehand too.
Hence, I think it would be quite useful if protoc-gen-es had an option to also generate a DescriptorSet that we could then use to more conveniently create registries at runtime. Thoughts?
The text was updated successfully, but these errors were encountered: