Basic aliases (e.g. `admin?`/`be_admin`) can be represented easily with simple
wildcards, but more complex transformations require a different mechanism.
Instead of using `%s` to represent strings that can be replaced 1:1, this
introduces a syntax inspired by https://github.com/tpope/vim-projectionist, as
such:
- name: Rails
aliases:
- from: "*Validator"
to: "{snakecase}"
This would find `AbsoluteUriValidator` and also match `absolute_uri`, which
would be found if the validation was in use.
This currently supports the `camelcase` and `snakecase` transformations,
as well as no transformation.
Closes#18
Why?
====
Dynamic languages, and Rails in particular, support some fun method
creation. One common pattern is, within RSpec, to create matchers
dynamically based on predicate methods. Two common examples are:
* `#admin?` gets converted to the matcher `#be_admin`
* `#has_active_todos?` gets converted to the matcher `#have_active_todos`
This especially comes into play when writing page objects with predicate
methods.
This change introduces the concept of aliases, a way to describe the
before/after for these transformations. This introduces a direct swap
with a wildcard value (%s), although this may change in the future to
support other transformations for pluralization, camel-casing, etc.
Externally, aliases are not grouped together by term; however, the
underlying counts are summed together, increasing the total occurrences
and likely pushing the individual method out of "high" likelihood into
"medium" or "low" likelihood.
Closes#19.
Why?
====
This ensures no method/function bleed between languages, which may cause
confusing miscalculation when methods/functions are reused across
different types of projects (e.g. index from Rails migrations and index
action from Phoenix controllers).
Why?
====
Handling low likelihood configuration was previously a huge pain,
because the syntax in Haskell was fairly terse. This introduces a yaml
format internally that ships with the app covering basic cases for
Rails, Phoenix, and Haskell. I could imagine getting baselines in here
for other languages and frameworks (especially ones I've used and am
comfortable with) as a baseline.
This also paves the way for searching for user-provided additions and
loading those configurations in addition to what we have here.
