We applied the Capybara/SpecificMatcher in commit f52a86b46. However,
this rule doesn't convert methods finding <a> tags to methods finding
links because <a> tags only count as links when they've got the `href`
attribute. For instance, in the `xss_spec.rb` file we check what happens
when clicking on an anchor tag because we're testing that the `href`
attribute has been removed and so we can't use `click_link`.
So, basically, we can't enable a rule to automatically detect when we're
using `have_css` instead of `have_link`, but we should still do it
because `have_link` adds an extra check which affects accessibility
since it makes sure the tag has the `href` attribute and so it's
recognizable as a link by screen readers.
This rule was added in rubocop-factory_bot 2.23.0. Even if we always
follow it, it's a mistake that we've accidentally made in the past
during development.
This rule was added in rubocop-rspec 2.19.0.
When freezing time in a test, `travel_back` is called automatically when
the test finishes, so we can do it in a `before` block instead of an
`around` block.
Note this rule didn't detect our usage of `freeze_time` because we were
using it on cops with a certain tag, but I expect the rule to be able to
detect this usage in the future.
Internet Explorer 8 was released in 2009 and people using it already
know that most web pages look broken on it, so we don't need to warn
them.
Removing it makes our application layout file much easier to read and
modify.
This rule was added in rubocop 1.44.0. It's useful to avoid accidental
`unless !condition` clauses.
Note we aren't replacing `unless zero?` with `if nonzero?` because we
never use `nonzero?`; using it sounds like `if !zero?`.
Replacing `unless any?` with `if none?` is only consistent if we also replace
`unless present?` with `if blank?`, so we're also adding this case. For
consistency, we're also replacing `unless blank?` with `if present?`.
We're also simplifying code dealing with `> 0` conditions in order to
make the code (hopefully) easier to understand.
Also for consistency, we're enabling the `Style/InverseMethods` rule,
which follows a similar idea.
We originally added the `cached_votes_up > 0` in commit 4ce95e273
because back then `cached_votes_up` was used in the denominator. That's
no longer the case, and it doesn't make sense to mark a debate with 1
vote and 10 flags as conflictive but not doing it when the debate has no
votes and 1000 flags.
We're fixing the bug right now because we're about to change the
affected line in order to apply a new rubocop rule.
The code based on the logger Rails uses by default; as mentioned in the
Rails configuration guide:
> [the logger] defaults to an instance of ActiveSupport::TaggedLogging
> that wraps an instance of ActiveSupport::Logger which outputs a log to
> the log/ directory. You can supply a custom logger, to get full
> compatibility you must follow these guidelines:
>
> * To support a formatter, you must manually assign a formatter from
> the config.log_formatter value to the logger.
> * To support tagged logs, the log instance must be wrapped with
> ActiveSupport::TaggedLogging.
> * To support silencing, the logger must include
> ActiveSupport::LoggerSilence module. The ActiveSupport::Logger class
> already includes these modules.
This rule was added in rubocop 1.37.0. It's particularly useful in the
background image spec, since now there's one less backslash to decipher
when reading the code :).
This rule was added in rubocop-rspec 2.14.0. Even though we always
follow this rule, we haven't always done so in the past. Now we're
making sure we'll keep following this rule.
This rule was added in rubocop-rspec 2.12.0, and we were already
following it most of the time.
However, the rule isn't working correctly in some cases, such as input
selectors, so we aren't enabling it.
This rule was added in rubocop-rspec 2.11.0. We aren't adding it
because, out of 3 offenses, this cop can only correct 2 automatically.
Not sure how to correct the other one since it uses `.and change`.
This rule was added in rubocop-rspec 2.9.0.
We were using `be_nil` 50% of the time, and `be nil` the rest of the
time. No strong preference for either one, but IMHO we don't lose
anything be being consistent.
This rule was introduced in rubocop-rails 2.18.0.
Since using `response.parsed_body` is shorter than using
`JSON.parse(response.body)`, this also means we can group some lines in
one.
This rule was introduced in rubocop-rails 2.17.0.
We don't use `where.not` with multiple conditions anywhere, but if we
did, it would indeed be very confusing, so we're adding a rule to avoid
that scenario.
This rule was added in rubocop-rails 2.16.0. Even if we always follow
it, sometimes developers don't realize about this mistake immediately,
so it's good to have a rule to guarantee it won't happen.
We were getting warnings due to an incompatibility between pg 1.5.x and
Active Record. I thought it was fixed in Active Record 6.1.x, but it
isn't, so we're using pg 1.4.x until we upgrade to Rails 7.
The warning was:
```
PG::Coder.new(hash) is deprecated. Please use keyword arguments instead!
Called from
activerecord-6.0.6.1/lib/active_record/connection_adapters/postgresql_adapter.rb:883:in
`new'
```
This reverts commit c03f4243f.
