Run CI against minimum supported Sorbet version

[sambostock]

Motivation

In #1046 (comment), there was a proposal to use a syntax that would not have been supported on the version of Sorbet we list as our minimum. It occurred to me that something in CI should exist to catch that sort of thing.

Therefore, this PR's goal is to extend the CI matrix to run against the minimum version of Sorbet which we claim to support. This way, we're able to detect incompatibilities as they are introduced, and either alter the implementation or version requirement, keeping the gemspec accurate.

Implementation

• The existing gemfiles are refactored to reduce duplication.
• A new gemfile is introduced which specifies an exact version of sorbet-static-and-runtime matching the minimum version we list in gemspec.
  • Ideally this would be dynamic somehow, so we don't have to update it.

Tests

No new tests should need to be introduced, but this branch actually already discovers that the version we specify as our minimum doesn't actually exist.

I suspect we were previously specifying matching versions of sorbet, sorbet-static, and sorbet-runtime, which we then migrated to sorbet-static-and-runtime (keeping the same version number), without realizing the version number started later than our "current" version.

[sambostock]

As noted in my description, this matches the minimum version we specify in tapioca.gemspec (">= 0.5.9204").

1. This version does not exist.
   We should either switch to a version number that does exist, or fallback to specifying Sorbet dependencies individually.
2. Ideally we'd do this dynamically so this file doesn't need to be kept in sync.
   Perhaps simplest to just do string matching on the Gemfile and extract the version?

[Morriar]

For 1. I think we should first create a PR that bumps the version to an existing one. The first version for sorbet-static-and-runtime is v0.5.9519 which is almost a year old. We can bump to something more recent.

[sambostock]

I've opened #1260 which starts by bumping to the first version.

What version do you think we should use as the requirement? We could go with the latest, but I'm not sure if we want to force the update for consumers.

[Morriar]

Let's keep the one you used in #1260 for the time being 👍

Thanks!

[sambostock]

To tie up loose ends, #1260 ended up bumping us to the first version that allows us to remove our feature flag checks (because all features are supported).

spec.add_dependency("sorbet-static-and-runtime", ">= 0.5.9892")

[sambostock]

Okay, I had to nudge it forward again to 0.5.9896, because 0.5.9892 doesn't actually exist either 😅

[Morriar]

I'm not convinced on the need to pollute the default Gemfile just for the sake of avoiding duplication in the gemfiles used for tests.

What do you think about creating an ERB template for the test gemfiles that could be parameterized based on the Rails version we want to test and the sorbet version parsed from the gemspec?

[sambostock]

The thing is that if we do that, we still end up duplicating the rest of the Gemfile, which leads to it becoming out of sync (as it currently is on main).

I based this approach off the approach taken by Shopify/maintenance_tasks, although I used instance variables differently due to differences in the arguments to gem (specifically, the presence of require: false).

Specifically with regards to using a template, that would mean we'd have to have a step in CI that renders the template before bundle install reads it, but that would necessarily mean doing it before installing any gems, which might be problematic.

Honestly, the cleanest solution would be if we were able to do something like

eval_gemfile "../Gemfile" # Containing a regular gemfile

override do
  # No complaint about duplicate gem specification
  gem("rails", "~> 6.1.0", require: false)
end

But AFAIK Bundler doesn't support anything like that.

[dirceu]

IMO removing that duplication (and the chance for them to get out of sync) justifies the change here.

[st0012]

Not saying this is better, but in this project I use env var to control which version to use (from Rails 5 to main).

Pros:

• We only need 1 Gemfile and logics are concentrated
• No warnings AFAICT

Cons:

• If conditions

[dirceu]

IMO removing that duplication (and the chance for them to get out of sync) justifies the change here.