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

Generated message types from .bin vs. runtime DescriptorSet #489

Closed
fubhy opened this issue May 16, 2023 · 4 comments
Closed

Generated message types from .bin vs. runtime DescriptorSet #489

fubhy opened this issue May 16, 2023 · 4 comments

Comments

@fubhy
Copy link
Contributor

fubhy commented May 16, 2023

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:

// From previously generated message types ...
createRegistry(...types); // Spread in all types after collecting them from all the generated code.

// From file ...
createRegistryFromDescriptors(createDescriptorSet(fs.readFileSync(...)))

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 a MessageType.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?

@smaye81
Copy link
Member

smaye81 commented May 17, 2023

How would this work though because the data inside the FileDescriptorSet is runtime data. Were you thinking of generating a FileDescriptorSet file with all of the proto data populated somehow?

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?

@fubhy
Copy link
Contributor Author

fubhy commented May 17, 2023

It's the most intuitive for sure but it runs into the issue of runtime instanceof not matching the generated message types.

Those are absolutely desirable for ergonomics (typings, etc.).

What I'd like to see is an option in protoc-gen-es that produces some kind of structure that I can easily create a registry from that then also works with instanceof. It doesn't have to be a FileDescriptorSet (in fact that would probably be overkill indeed). Maybe just a flat array of all message types that could the be spread into createRegistry(...types);?

@smaye81
Copy link
Member

smaye81 commented May 19, 2023

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?

@smaye81
Copy link
Member

smaye81 commented Jul 10, 2023

@fubhy Going to close this but if you have any other concerns/questions, feel free to reopen.

@smaye81 smaye81 closed this as completed Jul 10, 2023
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

No branches or pull requests

2 participants