Homebrew
Reduce size of rubocop.rbi
Verification
- [x] This issue's title and/or description do not reference a single formula e.g.
brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.
Provide a detailed description of the proposed feature
The tapioca-generated rubocop.rbi file is currently 60k lines / 1.69 MB, which is over 10% of the LoC in the repo (using the output of git ls-files -z | xargs -0 cat | wc -l as a base), and growing with each rubocop release.
The bloat is mostly because each cop is represented as a class, along with the methods it implements. We likely only need a few files for typechecking, such as https://github.com/rubocop/rubocop/blob/master/lib/rubocop/cop/base.rb and cops that we extend (e.g. MutableConstant)
We have some existing code that overrides what we require when generating tapioca definitions, let's try overriding the default behavior to limit what we load when creating the rubocop rbi file.
What is the motivation for the feature?
This file is currently the ceiling on what we allow to be pushed to the repo. By resolving this issue, we should be able to reduce the limit back to 1MB or lower (unless something else sneaks in while we have the higher limit).
How will the feature be relevant to at least 90% of Homebrew users?
Possibly, a less bloated git history, resulting in marginally better performance in some workflows.
What alternatives to the feature have been considered?
We could just keep nudging up the push limit as rubocop.rbi grows.
Looks like require.rb doesn't work like we think it does? My tests of regenerating with c8196df217057f7d62759976d9cb515db552e06f have been unsuccessful.
@issyl0 I player around with this a while back, I think I found the issue was that rubocop was required in tapioca compilers. I think that commenting out those compilers made that approach workable (though that was just to satisfy my curiosity, I'm not advocating for that approach). But, that was months ago, I may be misremembering.
New idea, since none of the piecemeal approaches to actual generation have worked. Can we generate the whole RBI file and then, as part of brew tc --update, parse it and delete the definitions we don't want? It's hacky, but...?
@issyl0 I'm +1 to seeing where that approach gets us. It might be both easier and make more sense when implemented as a tapioca compiler though (just emit the required rbi subset of rubocop, while excluding rubocop in the tapioca config).