AliSoftware
commented
3 years ago I actually looked quickly at Sorbet while I was working on the refactoring, as I was really annoyed by the lack of type-checking and the fragility of such a refactoring too! Great minds… 😉
I didn't know about RBS, and I'm not entirely sure I understand the project: is the code written in RBS supposed to be compatible with Ruby? Or are we supposed to run some rbs command on the code written in RBS to transpile it into Ruby? Or are .rbs files independent from .rb files and here to provide a grammar that we have to maintain ourselves in parallel to the real code? Not entirely clear to me which is which and how that's supposed to work…
In that regard, the documentation for Sorbet feels more clear to me, they clearly say that it's compatible with bare Ruby and I can totally see how they would achieve that. But I've never used either of those tools either, so would require some experimentation. Maybe a good candidate for upcoming Hack Week?
What I was surprised about when I Googled for any ruby type-checker solution, is that I only found things like Sorbet, which requires annotating your Ruby code with actual ruby instructions/annotations. I was very surprised not to find any solution out there that would build on top of YARD documentation, and leverage the types documented in the YARD comments to do the type-checking, instead of having to duplicate the information both in YARD doc and in annotations like sig {…} in Sorbet.
If any of you have knowledge of any tool that would provide type-checking on top o the YARD documentation annotations, instead of having to add another set of annotations that would kinda duplicate the ruby documentation and having to maintain both in sync and all, I'd love to hear it!!!
What do you think of adding static type checking, either via RBS (
which would require upgrading to Ruby 3.xRBS requires Ruby >= 2.6) or sorbet?I love that we are putting effort in documentation and writing good Ruby to help us compensate for the lack of type checking. Those are great initiatives that we should definitely pursue but I wonder if we could augment them with the introduction of static type checking.
@jkmassel showed me a similar approach using Psalm for PHP in an internal project and I found it super useful.
Note: I never used either of those tools but I imagine seriously adopting them would be quite a process. I'm not arguing we should jump onto it right away, I'm just curious of your opinion. If there's interest, we should run an humble spike first, just to see if it's straightforward to adopt them and if type-annotated classes can coexist with non-type-annotated ones, allowing us a gradual adoption path.