closure_js_proto_library targets as dep "is neither a TypeScript nor a JS producing rule."

[pshields]

This is a tracking issue to get ts_library to work with closure_js_proto_library deps.
Currently, when a closure_js_proto_library rule is provided as a dep to a ts_library rule, the ts_library fails to build with the error that the dep is "neither a TypeScript nor a JS producing rule." However, closure_js_proto_library does generate a JS output at bazel-genfiles/path/to/<target_name>.js.

[pshields]

Alternatively, is there a different build rule people should use to consume protobuf codegen from TypeScript?

[pshields]

This may be an issue with the implementation of assert_js_or_typescript_deps at https://github.com/bazelbuild/rules_typescript/blob/89d2c75066bea3d9c942f29dd1d2ea543c58d6d5/internal/common/compilation.bzl#L67

It's checking for a 'js' attribute on the closure_js_library in order to determine whether the rule generates JS or not. I'm not sure what the semantics of the 'js' attribute are, so I'm not sure if it's a bug in closure_js_proto_library or assert_js_or_typescript_deps.

[alexeagle]

Will do bazelbuild/rules_typescript#61 first, I hope to not support closure library stuff as it's not widely adopted.

[alexeagle]

Update: with @oferb we tried again to do this in the context of grpc.
improbable-eng/ts-protoc-gen#92 was useful to get a JSPB codegen that looks like a ts_library-shaped dependency, getting one step further than @pshields above.

Then we ran into the next issue which is that jspb codegen only contains commonjs module syntax, and this needs to be adapted to named AMD or UMD to work with ts_devserver.

Another step would be to get it working with rollup_bundle as @Globegitter demonstrates in https://github.com/Globegitter/rules_typescript_grpc_example

I'm not currently working on this but it could use some community contribution.

[alexeagle]

In fixing this we should also test that it works with https://github.com/stackb/rules_proto to generate protobuf clients. When we use commonjs_grpc_compile to generate our gRPC code

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 90 days. It will be closed if no further activity occurs in two weeks. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

[github-actions]

This issue was automatically closed because it went two weeks without a reply since it was labeled "Can Close?"