Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Static Type Checking 🤔 #201

Open
mokagio opened this issue Feb 2, 2021 · 2 comments
Open

Static Type Checking 🤔 #201

mokagio opened this issue Feb 2, 2021 · 2 comments

Comments

@mokagio
Copy link
Contributor

mokagio commented Feb 2, 2021

What do you think of adding static type checking, either via RBS (which would require upgrading to Ruby 3.x RBS 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.

@AliSoftware
Copy link
Contributor

AliSoftware commented Feb 2, 2021

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!!!

@AliSoftware
Copy link
Contributor

Seems that RBS, TypeProf and Sorbet are maturing and made promising progress as part of Ruby 3:

Maybe worth revisiting those to see if we could use those on this repo to have at least partial type checking (†) of our release-toolkit code?

(†) I'm not sure RBS / TypeProf would be smart enough to be able to detect that options[:foo] is supposed to be of the type indicated by the corresponding ConfigItem(key: :foo, type: …) in a Fastlane::Action subclass, so it might not detect everything there… but if it can already help with helper codes and regular functions, that'd already be an improvement!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants