Provide per-framework runtime dependency packages

[doctorpangloss]

The package should just reference its requirements and the end user should rely on tree-shaking to omit packages that are unused in clients. Otherwise your documentation should be modified to specify which versions of which packages should be imported for which features.

[stephenh]

I think something like ts-proto-grpc / ts-proto-twirp / etc. dedicated npm packages would be good to provide clients with a way to get the set of dependencies they want.

But, personally I would not want, say, grpc-web dependencies hitting my node_modules/ if I'm never going to use it; just in the vein of node_modules/ are already bloated for JS projects as-is.

Also, the core ts-proto package is "just the code generator", and not something the actual runtime application would depend on anyway.

I'll re-name this as "provide per-framework packages for runtime dependencies". Assuming that achieves your goal, PRs would be great, even if it's just for the framework you're currently using/care about.

(I.e. like ts-proto/dependencies/grpc-web that publishes a new ts-proto-grpc-web package, ts-proto/dependencies/grpc-js that publishes a new ts-proto-grpc-js package, etc.)