Twirp support

[SamMorrowDrums]

In order to support Twirp, specifically Twirp Ruby, I believe a DSL would be necessary. The GRPC stuff is already handled well, and correct types are generated however, but the types are left out from the functions defined by Twirp, and so we end up very close, but still untyped sadly.

I had opened this issue previously, but I believe it was not highlighting the correct issue.

If somebody already has a way to do this without needing to add Twirp to Tapioca I'd also love to know, but it would be great if this can be supported as it's likely a fairly small lift, given the RPC stuff does all the heavy lifting.

[SamMorrowDrums]

A colleague already has an implementation (replaced our names with xxx):

# typed: true
# frozen_string_literal: true

require xxx
require "tapioca/dsl/compilers/protobuf"

module Tapioca
  module Compilers
    # xxx creates RBI definitions for each one of our twirp
    # clients so that their return types are correct. Otherwise we would be
    # relying on `tapioca gem` which treats them as `T.untyped`.
    #
    # See: https://github.com/Shopify/tapioca#writing-custom-dsl-compilers
    class Xxx < Tapioca::Dsl::Compiler
      extend T::Sig

      # This declares the type of the `constant` in `root.create_path` and
      # allows for type checking it.
      #
      # This is how a generic looks in sorbet.
      ConstantType = type_member { { fixed: T.class_of(::Twirp::Client) } }


      # gather_constants list the constants that need to be decorated.
      sig { override.returns(T::Enumerable[T.class_of(::Twirp::Client)]) }
      def self.gather_constants
        # Collect all the Twirp clients on the xxx namespace
        ::Twirp::Client.subclasses
          .select { |klass| klass.name&.start_with?("Xxx:Proto") }
      end

      sig { override.void }
      def decorate
        root.create_path(constant) do |klass|
          # For each one of the RPC calls on a client, we create method that has:
          #
          # - A return type of `Twirp::ClientResp[MethodRespType]`
          #
          # The RPC related methods come from the protobuf definitions
          # themselves as they already have really good reflection mechanisms.
          constant.rpcs.each do |rpc_name, rpc_config|
            klass.create_method(
              rpc_config[:ruby_method],
              return_type: "::Twirp::ClientResp[#{rpc_config[:output_class]}]",
              parameters:  [create_param("request", type: rpc_config[:input_class].to_s)]
            )
          end
        end
      end
    end
  end
end

[KaanOzkan]

I don't have context on the methods generated by Twirp so it'll be good to have an explicit documentation similar to https://github.com/Shopify/tapioca/blob/main/lib/tapioca/dsl/compilers/active_record_associations.rb#L11.

If you want to automate hand written RBIs then yes you can probably achieve that using a DSL compiler. We'd prefer if it lived in twirp-ruby gem since they are coupled together. It'll be easier to maintain.

Also your implementation looks okay, these are the docs for writing a custom compiler if you need assistance. One thing that jumps out is the gather_constants loop, you should use all_classes instead. It's memoized and takes into account arguments to tapioca dsl which can lead to faster execution.

We also ship the test helpers as part of tapioca in https://github.com/Shopify/tapioca/tree/main/lib/tapioca/helpers/test so you can test your compiler as if you're developing inside tapioca. Going through the existing DSL compiler tests will be helpful.