- This was done with `brew typecheck --update --suggest-typed` which
(as of the previous commit) uses Spoom, yet another gem. I thought I'd
see how well it works. There are no Sorbet errors after these changes!
The `tags_only_debian` code in livecheck's `Git` strategy was
originally introduced in Homebrew/homebrew-livecheck#131 when
livecheck was in a less mature state and relied more on internal
special-casing like this (i.e., while we worked to add appropriate
`livecheck` blocks). This logic only has the potential to be
beneficial when a formula/cask doesn't contain a `livecheck` block
but I would argue that we shouldn't be making assumptions in the
strategy around whether tags with a `debian/` prefix should be
matched or omitted. The answer depends upon the context of a given
formula/cask and should be handled with a `livecheck` block, as we
do with other situations like this.
In a past discussion, it was preferred that we use `system_command`
in livecheck's `Git` strategy instead of `Open3.capture3` but it
wasn't feasible at the time because we couldn't prevent
`#system_command` from printing certain output. I resolved the
`SystemCommand` shortcoming long ago in Homebrew/brew#10066, so this
finally migrates the `Git` strategy to `system_command`.
There are times where a regex isn't needed in a `strategy` block and
these changes explicitly handle that situation.
This allows the Symbol Proc format used in some `Sparkle` `livecheck`
blocks (e.g., `strategy :sparkle, &:version`) to continue working
instead of failing with a "wrong number of arguments (given 1,
expected 0)" error. This error would occur because a Symbol Proc only
only expects one argument (e.g., an `Item`, not an `Item` and a
regex/nil).
There's an argument to be made for avoiding the Symbol Proc format
for `strategy` blocks but I haven't found a way of selectively
disabling the Style/SymbolProc cop only for a `strategy` DSL method
call. That is to say, if we don't use the Symbol Proc format, `brew
style` will give a "Pass &:version as an argument to strategy instead
of a block." offense.
Besides that, this also replaces the `block` type signatures in
livecheck strategies with `T.untyped`. Sorbet doesn't know how to
handle a `Proc` with a variable number of arguments and can't be
taught how (i.e., `T.any` with a `Proc` signature for each variation
doesn't work). The aforementioned changes cause Sorbet to complain
about there being both too many and too few arguments, so the only
way to win is not to play the game. Hopefully we can restore the
`block` type signatures in the future (if upstream resolves this
years-old issue) but `T.untyped` seems to be our only option for now.
Valid `strategy` block return types currently vary between
strategies. Some only accept a string whereas others accept a string
or array of strings. [`strategy` blocks also accept a `nil` return
(to simplify early returns) but this was already standardized across
strategies.]
While some strategies only identify one version by default (where a
string is an appropriate return type), it could be that a strategy
block identifies more than one version. In this situation, the
strategy would need to be modified to accept (and work with) an
array from a `strategy` block.
Rather than waiting for this to become a problem, this modifies all
strategies to standardize on allowing `strategy` blocks to return a
string or array of strings (even if only one of these is currently
used in practice). Standardizing valid return types helps to further
simplify the mental model for `strategy` blocks and reduce cognitive
load.
This commit extracts related logic from `#find_versions` into
methods like `#versions_from_content`, which is conceptually similar
to `PageMatch#page_matches` (renamed to `#versions_from_content`
for consistency). This allows us to write tests for the related code
without having to make network requests (or stub them) at this point.
In general, this also helps to better align the structure of
strategies and how the various `#find_versions` methods work with
versions.
There's still more planned work to be done here but this is a step
in the right direction.
