How does Tapioca compare to `srb rbi`?

Commands mapping between srb rbi and tapioca

srb	tapioca
srb init	tapioca init
srb rbi config	tapioca config
srb rbi sorbet-typed	tapioca annotations
srb rbi gems	tapioca gems
srb rbi hidden-definitions	Partially covered by tapioca dsl
srb rbi todo	tapioca todo
srb rbi suggest-typed	Delegated to spoom bump
srb rbi find-gem-rbis	Folded inside tapioca gems

The description of each Tapioca command can be found in the README.

Comparison between srb rbi gems and tapioca gems

srb rbi gems does indeed generate RBI files for gems and historically both tapioca and the srb tool date back to the same in-house Stripe code snippet for generating RBIs for gems. So, there are a lot of overlaps.

However, we have taken a slightly different route in building tapioca gems than the Sorbet team has with srb rbi gems that we feel make a big difference.

1. With tapioca, you are in complete control over which gems get loaded and how. We provide both prerequire and postrequire files that can do require calls so that you have the option to load all the code that you need RBI generation for into memory. tapioca handles the rest. You will need this for any gem that is marked require: false in the Gemfile and/or for any non-default part of a gem that you are requiring in your codebase explicitly.

   In contrast, this hard-coded lookup table is what srb rbi gems provides. We didn't feel like maintaining a set of such lookup tables was going to be maintainable or desirable, so went a different way.

2. tapioca tries really hard to load all of your gem dependencies regardless of groups or other conditions, so that we can generate RBI files for all of your dependencies regardless of which environment you are using for RBI generation. I am not sure if srb does anything similar, but the last time we checked, it wasn't.

3. tapioca also does not rely on a pre-defined set of constants to start discovering other constants from like how srb does (again via the same lookup table). Instead, tapioca internally uses Sorbet to parse all of the code inside a gem to discover the statically analyzable types that is defines, and starts walking over those to do a better job of spanning all of type definitions in the gem. srb, by design, might miss some, since it depends on the internally defined constants.

4. tapioca, again, tries really hard to figure out which gem each type belongs to and generates individual and versioned RBI files for each gem. In contrast, srb generates individual RBI files but primarily relies on Tracepoint to decide on which file a type belongs to. This might not create the best solution in the most general case.

5. Due to the versioning of RBI files generated by tapioca, it can, in most cases, only generate the RBI files of gems that have been added/updated and can remove the files that no longer have a matching gem definition.

6. tapioca can generate extension methods to built-in types and AFAIK, srb does not currently do that (or ends up generating all the methods on the extended core class and not just the ones that were added).

7. As of the most recent version, tapioca can generate RBI files with signatures if the source gem has inline signatures. We have not seen the srb tooling do that yet.