-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
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 In that regard, the documentation for 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 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!!! |
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 |
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.
The text was updated successfully, but these errors were encountered: