Proof of concept: Filter gem RBIs by version during annotations command

[egiurleo]

Motivation

This proof of concept aims to solve the problem of versioning RBIs. Up until now, there is no default way to write RBI for different versions of the same gem. This can lead to confusing issues for Sorbet users where RBIs don't match the version of a gem they're using, and they have to spend time figuring out whether their gem is out of date, whether the RBI is wrong, or if it's even both! Having a way to specify RBI for multiple versions of the same gem would allow people to adopt and use Sorbet without having to go through this hassle.

Implementation

The actual RBI filtering behavior is implemented in the RBI repo. This uses the FilterVersions rewriter during the annotations command to remove parts of the annotation RBI that aren't relevant to a certain gem version.

Tests

I have added a test for this functionality.

Further work

This is just a proof of concept to get a sense of how people are feeling before I invest more time in this. If I kept working on it, I would add:

• Perhaps an experimental flag?
• Config/CLI options to enable and disable this functionality?
• Documentation

[paracycle]

I have a few inline comments, but additionally:

Is this still a "Proof of concept"? I think once we merge this, it will ship in the next release, right?

[paracycle]

I am finding it really hard to understand what this code is doing.

Is this something other than:

Suggested change

	gem_names_and_versions = T.let(Hash.new { |h, k| h[k] = [] }, T::Hash[String, ::Gem::Version])
	parser.specs.each_with_object(gem_names_and_versions) do |spec, hash|
	hash[spec.name] = spec.version
	end
	gem_names_and_versions = parser.specs.to_h do |spec|
	[spec.name, spec.version]
	end

[paracycle]

Is there a special reason why we are reaching for a hash instead of a custom data structure?

If we were to build something like:

class GemInfo < T::Struct
  const :name, String
  const :version, ::Gem::Version
end

then, the changes in this PR will be more more minimal, and the code will be easier to read, IMO.

For example, this line will instead be:

Suggested change

	sig { returns(T::Hash[String, ::Gem::Version]) }
	sig { returns(T::Array[GemInfo]) }

and you would have preserved the return of an array.