Please separate CLI part of types loading (that uses yargs) from actual proto loading code

[koteisaev]

Is your feature request related to a problem? Please describe.

If the packages dependency tree contains the @grpc/proto-loader, as it happens with google-gax, it pulls with that a lot of code related to command line processing, such as yargs package and all its 40+ packages from dependencies.

Describe the solution you'd like

Most likely solution would be to separate the cli-specific functionality and its specific dependencies into something like @grpc/proto-loader-cli and use it via npx when necessary.

Describe alternatives you've considered

There is no way for me to do an alternative as this is a deep dependency of packages I use, such as @google-cloud/datastore which refers the google-gax which refers the @grpc/proto-loader surely without CLI-specific processing but for API calls using paths to proto files known by calling code.

Additional context

This will allow to get rid of dozens of dependencies which never called even indirectly in normal usage scenario of google-gax library (via Google Cloud client libraries and alike).

[Delapouite]

Yes I agree.

Another big ecosystem that would benefit from a lighter dependency tree, is @opentelemetry packages that need to export metrics, logs and traces via gRPC.

[murgatroid99]

I agree that this would be a reasonable change to make. One concern I have is that the code generation and runtime code share some internal APIs, and separating them would require either making the APIs public or duplicating their functionality. Either way, it would be good to have a proposal to design how this split would be accomplished. Unfortunately, I don't have the bandwidth to work on that, but if someone wants to do the work themselves, I would be happy to work with them on this.