-
Notifications
You must be signed in to change notification settings - Fork 83
Rails application type generator #99
Rails application type generator #99
Conversation
* Rails is a module, not a class * Superclass was missing * Different format for method definition, similar to gem types
Codecov Report
@@ Coverage Diff @@
## master #99 +/- ##
========================================
+ Coverage 98.95% 99% +0.05%
========================================
Files 142 145 +3
Lines 1242 1306 +64
========================================
+ Hits 1229 1293 +64
Misses 13 13
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very interested in this work.
The conflict sig is a challenging issue. I think (2) is not the right approach because the file can contain other signatures as well. Removing the file will remove more than the application signature. Let's post in sorbet-ruby slack and see what the sorbet team suggest. |
Here's the Parlour version of the RBI generator: root.create_class(Rails.application.class.name, superclass: 'Rails::Application')
rails_module = root.create_module('Rails')
rails_module.create_method(
'application',
return_type: Rails.application.class.name,
class_method: true
) |
Closing because this PR has been outdated for a long time. @bradleybuda If you still want to make the change, please send another PR based on the newest code |
A first attempt to fix #98. The code is straightforward, but it has a (fatal) issue - the
Rails#application
type I'm generating inrake rbi:application
conflicts with theRails#application
type defined in sorbet-typed, and I don't know what the resolution rules in sorbet are when two different.rbi
files try to define different signatures on the same method - from playing around, I think the "last one in" wins, but it's not clear if this is well-defined or how we'd exploit it.Some possible fixes:
Rails.application
types fromsorbet-typed/railties
. This feels wrong because it makes sorbet less useful for Rails users who are notsorbet-rails
users, and creates a backwards maintenance dependency fromsorbet-typed
tosorbet-rails
.sorbet/rbi/sorbet-typed/lib/railties/all/railties.rbi
file. This is potentially fragile but it doesn't seem crazy to "manage" vendored types.Thoughts? I'm going to proceed with option 2 for now.