We were already using it in most places.
Note that enabling this rule means we've got to change a few lines in
order to follow the LineEndStringConcatenationIndentation rule. In the
link list tests, the easiest way to do so was to use heredoc instead,
which IMHO improves readability over the previous version.
We forgot to remove it in commit 8066b96fe. We're removing it now
because these methods didn't follow the Layout/BlockAlignment rubocop
rule, which we're about to add.
For the HashAlignment rule, we're using the default `key` style (keys
are aligned and values aren't) instead of the `table` style (both keys
and values are aligned) because, even if we used both in the
application, we used the `key` style a lot more. Furthermore, the
`table` style looks strange in places where there are both very long and
very short keys and sometimes we weren't even consistent with the
`table` style, aligning some keys without aligning other keys.
Ideally we could align hashes to "either key or table", so developers
can decide whether keeping the symmetry of the code is worth it in a
case-per-case basis, but Rubocop doesn't allow this option.
We were already applying these rules in most cases.
Note we aren't enabling the `MultilineArrayLineBreaks` rule because
we've got places with many elements whire it isn't clear whether
having one element per line would make the code more readable.
Since IRB has improved its support for multiline, the main argument
towars using a trailing dot no longer affects most people.
It still affects me, though, since I use Pry :), but I agree
leading dots are more readable, so I'm enabling the rule anyway.
Not sure exactly since when, but we've started to get rubocop failures
when using the pattern:
respond_to do |format|
format.js
end
We've been using this pattern for ages, so maybe a recent version of
Rubocop introduced a change that made it report it.
In any case, this is easier to read than respond_to(&:js), so we're
allowing it.
We added the `user_id` rule in commit edaf420f5. To be honest, I'm not
sure what we meant, since I haven't found URLs containing the user id.
So we're treating it as if it was a typo and we wanted to do the same
thing we did with other parameters.
In the `i18n_translation` initializer, we're overwriting the `t` helper
so calling it uses custom translations if they're available.
However, ViewComponent doesn't use the `t` helper but implements its own
`t` method. So, when calling the `t` method in a component, we weren't
using our implementation of the `t` helper, and so we weren't loading
custom translations.
Using the `t` helper in components solves the issue.
There was a test where we were directly testing a method in a component,
and that method uses the `t` helper. This caused an error when running
the test:
ViewComponent::Base::ViewContextCalledBeforeRenderError:
`#helpers` can't be used during initialization, as it depends on the
view context that only exists once a ViewComponent is passed to the
Rails render pipeline.
Using `render_inline` in the test and testing the generated HTML, as
recommended in the ViewComponent documentation, solves the issue.
Webdrivers doesn't seem to be working with GitHub Actions since Chrome
changed the way to download ChromeDriver [1].
Luckily, webdrivers functionality has recently been added directly to
selenium-webdriver, and version 4.11.0 is compatible with the new way to
download ChromeDriver.
So we're updating selenium-webdriver and removing webdrivers.
Note we now have to use the `Options` class instead of the
`Capabilities`. We're updating Capybara since its changelog mentions its
latest version also adapts these changes in Selenium.
[1] https://groups.google.com/g/chromedriver-users/c/qVPTFXnedw0
From now on changes will be done using the GitBook interface, so
changing this repository won't have any effects.
So we're archiving the repository and linking to the documentation site.
It was obvious which project the comment was about. Also, no point
having a TODO referencing what to do after upgrading to Rails 5.1, since
we did it years ago.
