-
Notifications
You must be signed in to change notification settings - Fork 35
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
Option to configure custom module paths #53
Comments
hi, so far this is not supported. Could you please describe your idea? Is this for sharing it as a library or what is this for? |
General ideaSure thing: My idea is about, in fact, having the ability to create Angular packages when using multiple protobuf package definitions. import { ... } from '../a.pb'; Problem when creating an Angular packageNow, since a single Angular package is not able to provide TypeScript submodules due to its architecture, the only way is to separate each subdir containing protobuf generated files into an Angular sub package using ng-packagr. Thus, when splitting the generated files into multiple Angular sub-packages, we want to reuse code from other Angular packages that were created before. Code reuse is not possible when using relative paths, as files would be re-included multiple times thus increasing the package size and making things a bit more unmaintainable (multiple types for the same data structure). Also note that it is a technical limitation of an Angular package to include files from a parent directory, relative to the respective To stick to the example from above:
Now files could get imported from the following path
SolutionAs mentioned above, I would like to have a new option field for protocol packages like it is already provided by other proto generators such as the Go ( I suggest to name this option Note on protobuf package option fields: Protobuf options are specified to be optional by default. Introducing that module option would not break any files generated by I hope I elaborated the idea, problem & solution understandable. Thanks in advance. |
Thank you very much for detailed clarification! Yes, I see the problem. I think I need some time to think it through... Just a note: in case we'd need some custom option, it would be a good idea to submit a request to add it to the global list. |
I didn't knew about that list! |
:) yep, protobuf is really deep... actually, I thought many times to have custom options, but this step seems a bit heavy to perform. That's why normally all the customizations that are possible in ngx-grpc are done in the config file. However, this case cannot be solved with config file => probably it's a good idea to think of registering the option. |
Still, it waits. It's not yet clear how to fully handle the npm package structure + how to refer within this package + how to deal with repeating names in exports etc. Let's give it some time |
But tbh the option I imagine wouldn't be an extension. As far as I know, package options are only available within the compile time. |
I'll create an example with deps and a simple package structure later on today. |
@smnbbrv Compiling a package using ng-packagr works fine without any problem. See my example repo: https://github.com/TheMysteriousVincent/ngx-grpc-library-example Since ng-packagr supports intra-dependencies, creating such a library is not a problem. Of course, there should be a script to automize creating the Your uncertainities
Let's split this up:
message AMessageServiceClient {}
service AMessageService {} Both name collision sources exist because of bad protobuf design. When those name collisions arise, the user should rethink his protobuf names. So, it is up to the user to create a false/duplicate entry. Since creating Angular libraries for gRPC services is a more advanced topic, we can definetely assume that the user knows what he does. |
@smnbbrv Any news on this? |
|
Hi there!
Is it currently possible to provide a custom module path to a protobuf package?
For example, when generating e.g. Go or C# files, it is possible to specify a custom module location/namespace using options:
If this is already implemented, please tell what the regarding option is called and if it is not implemented, would you like to do so?
Best regards,
Vincent
The text was updated successfully, but these errors were encountered: