Hacker News Reader

Comment by coreyja | Hacker News Reader

Do you have any tips or tricks for migrating a Rails app from Sorbet `srb rbi` generated files to one using Tapioca?

I was unsure exactly which bits of Sorbet rbi were still required with tapioca https://github.com/Shopify/tapioca/issues/114

We are currently using `sorbet-rails` but it appears Tapioca would be a replacement for that as well, is that correct?

View on HN

Ultimately, the goal is for Tapioca to replace all `srb rbi` tooling and `sorbet-rails`. Right now, we exclusively use Tapioca for gem RBIs and we don't use any `srb rbi` tooling at Shopify. That works perfectly fine, but you don't get any `sorbet-typed` RBIs, which, right now is not a concern for us.

The DSL generators are not 100% complete to fully replace `sorbet-rails` right now, but we are preparing a 1.0 release of the gem that should be able to do that.

Thanks for the reply!

> but you don't get any `sorbet-typed` RBIs, which, right now is not a concern for us.

Ahh ok! I think this might have been a bit I missed, cause I was commonly trying to do both which likely caused issues for me.

> The DSL generators are not 100% complete to fully replace `sorbet-rails` right now, but we are preparing a 1.0 release of the gem that should be able to do that.

Will keep my eyes open, thanks!

One of the challenges sorbet-rails faced [1] was with the usage of method_missing in certain places. The one that bit me was Rails automatically piping a class method from Model into the Model's CollectionProxy, effectively making class methods into scopes. We use this pretty extensively at work for complex scopes, so this is one of the reasons I've not been able to get complete buy-in for sorbet. Is that better in tapioca?

(Also: Thank you for sorbet! It's the biggest reason I continue to use Ruby for my personal projects.)

1: https://github.com/chanzuckerberg/sorbet-rails/issues/104

I am afraid that is a shared concern for what Tapioca is doing as well. There are ways of mitigating that concern, by, for example, lifting all static methods on a model to be methods on the collection proxy in RBI files. This is certainly doable, and we are less interested in the correct signatures for such methods than having the method definitions in place, in the first place. On the other hand, we also have some Sorbet feature ideas that we want to experiment with where we might be able to annotate that a certain type delegates all missing methods to another type, for example.

This is indeed a problem in our codebase as well, and so far our team has been suggesting that people add shim (i.e. manual) RBI definitions for the methods that they find are missing from the types they've expected them on. This is a good stop-gap measure to solve a problem that is not very common with an easy solution to implement.

Reply on news.ycombinator.com