You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, while the proto extension parses the proto file, it uses regex to find certain information about the file, including package, options, and imports.
For determining Java imports, we'd need to know the Java package option (already available) as well as the names of the messages and services being generated.
This feature request would be to add two new fields to FileInfo: ServiceNames and MessageNames (or something similar). In addition to the current information parsed from the proto file, we'd record this information and return it to the caller for later use.
We'd be happy to implement this and raise a PR, but wanted to understand any concerns with this approach before spending cycles on implementation.
The text was updated successfully, but these errors were encountered:
Currently, while the proto extension parses the proto file, it uses regex to find certain information about the file, including package, options, and imports.
One of the things being parsed is services. However, this is currently just to track a boolean on whether there are any services in the current file.
For determining Java imports, we'd need to know the Java package option (already available) as well as the names of the messages and services being generated.
This feature request would be to add two new fields to FileInfo:
ServiceNames
andMessageNames
(or something similar). In addition to the current information parsed from the proto file, we'd record this information and return it to the caller for later use.We'd be happy to implement this and raise a PR, but wanted to understand any concerns with this approach before spending cycles on implementation.
The text was updated successfully, but these errors were encountered: