Repository navigation
Please separate CLI part of types loading (that uses yargs) from actual proto loading code #3024
Description
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).
Activity
Delapouite commentedon Dec 14, 2025
Yes I agree.
Another big ecosystem that would benefit from a lighter dependency tree, is
@opentelemetrypackages that need to export metrics, logs and traces via gRPC.murgatroid99 commentedon Dec 19, 2025
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.