Add support for Rails generators

[michaelherold]

Motivation

Rails generators are application code, though not part of your main Rails application. The files are not automatically loaded when starting your app because Railties loads them when you run the generate command.

However, since it's part of your application, it's helpful to be able to enable strong typing within those files. Without knowing about the Thor-based DSL, you're left writing shims yourself.

Having support within Tapioca means that you won't have to manage this manually any more.

Implementation

I load the two most likely candidate files. There are others that we could load, for example:

• rails/generators/active_model
• rails/generators/erb
• rails/generators/generated_attribute

I didn't want to get into the rabbit hole of trying to load all of them because that would be brittle between Rails versions. Do you think that's the correct choice?

Also, in order to avoid generating RBIs for built-in classes, I opted for pattern matching on the class name. That doesn't feel great, but I wasn't sure what would be a better approach. There are two main base classes, Rails::Generators::NamedBase and Rails::Generators::Base, but there are also some in gems other than railties. Do you have suggestions on a better solution?

I had to add some RBIs for railties for type-checking since I use them in the tests. It appears that a prior version of Tapioca (or maybe Parlour?) wrote the existing file and that it used to include comments. Instead of including the big, messy diff, I included only the pieces that I needed. This leaves the file looking inconsistent because there are chunks in the new style and the rest is in the old. Is that okay, or should I rewrite the whole file? I rewrote the whole file.

Tests

Yep, there are tests for corner cases that I could think of.

[michaelherold]

I resolved the style nits and left the other two threads open with comments. Thanks!

[KaanOzkan]

Instead of including the big, messy diff, I included only the pieces that I needed

Feel free to include the big messy diff for railtie.rbi, since that's what tapioca outputted.

However, since this gem RBI update PR hasn't touched railtie I'm thinking that you didn't supply the --doc option? If that's the case please supply that and commit the RBI as a whole.

[paracycle]

I am not in love with the BUILT_IN_MATCHER gymnastics, but I guess this is the best way of excluding internal classes, for now.

Thanks for working on this and putting this together. Much appreciated.