Generating the files really isn't the issue here, and I agree that most users probably won't run into the issue of having multiple import syles in their build-graph. But I don't think just allowing different import styles is going to solve anyone's problem.

Let me explain this a little more detailed:
The current implementation of closure_grpc_web_library is highly coupled with rules_closure, thus cannot handle anything typescript related (effectively ruling out import_style={typescript,commonjs+dts}). There is some support for commonjs in rules_closure, but there is absolutely no way of pulling in the matching protobuf/grpc-web runtimes from npm, which would leave users with completely broken, thus most likely unusable targets.
Additionally, I don't believe that anyone asking for alternative import styles is interested in using rules_closure, and, AFAICT, closure_grpc_web_library will not work with other JavaScript Bazel rules like rules_nodejs or rules_typescript.

In the end, I think we will shoot ourselves in the foot if we start supporting other import styles in closure_grpc_web_library.
What I'd be open to is creating something like commonjs_grpc_web_library that allows import_style={commonjs,commonjs+dts,typescript} and integrates with rules_nodejs and rules_typescript. Then, folks could choose whether they want to use import_style=closure and rules_closure or import_style={commonjs,commonjs+dts,typescript} and rules_{nodejs,typescript}.
Does that sound like it could solve your use-cases?

import_style=typescript with Bazel? #550

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions