feat: generalize js_proto_toolchain() to work with other implementations

[acozzette]

Currently we are not set up to support any JavaScript or TypeScript protobuf implementations other than protobuf-es from Buf.build. This is because we have a hard-coded assumption that the protobuf plugin will produce files matching the .proto file name except with "_pb.js" and "_pb.d.ts" in place of ".proto". This assumption holds for protobuf-es but not for other implementations such as Google's protobuf-javascript implementation.

This change addresses that problem by adding a new output_file_extensions parameter on js_proto_toolchain() to allow users to specify the generated files they expect the plugin to produce.

To make this work, I had to copy most of the logic from the proto_lang_toolchain() rule into a new js_proto_toolchain() rule. This was necessary because we need a rule that continues to produce the ProtoLangToolchainInfo provider but additionally produces a new JsProtoToolchainInfo provider with the new file extension information we need.

---

Changes are visible to end-users: yes

• Searched for relevant documentation and updated as needed: yes
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: no

Test plan

• New test cases added

[alexeagle]

Did you confirm that other plugins actually make use of this new ability?

[acozzette]

Did you confirm that other plugins actually make use of this new ability?

So far I have only confirmed that it works with protobuf-es and Google's protobuf-javascript implementation, so I still need to confirm that for stephenh/ts-proto and timostamm/protobuf-ts.

[acozzette]

@alexeagle I'd like to clean up and improve my examples a bit, but otherwise I think this PR is about ready for a closer review when you have a chance. I was able to set up an example for each of the JS/TS implementations that Buf provides an SDK for.

Do you have any suggestions on the best way to make sure my examples run on CI?

[alexeagle]

is there a good reason not to just make these examples/ and part of the root module? then they are easier for users to discover and don't require maintaining nested modules or CI changes

[acozzette]

is there a good reason not to just make these examples/ and part of the root module? then they are easier for users to discover and don't require maintaining nested modules or CI changes

I think that should work. Once we have all four toolchains registered in the same module, I suspect we'll need a config transition to be able to choose the one we want for each example without requiring a command-line flag. Let me give that a try.

[acozzette]

I think I now have something mostly working that allows all the examples to live in the same module. It still needs a bit of cleaning up, though.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3f72c09ae8

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[acozzette]

@jbedard I think this is ready for another look whenever you have a chance.

[acozzette]

@jbedard I think this is now ready for another look. I'm not sure what the CI errors are about but maybe you have a better idea of what the problem is there?

[jbedard]

You can ignore the CI / org-check / * CI for now