The main reason for this change is that Pronto doesn't run in pull
requests opened by external contributors, and we haven't found how to
fix this issue.
Another reason is that Pronto only detects issues in the lines where the
changes are done, but sometimes we introduce issues related to other
lines and those aren't detected by Pronto. Also, when adding or changing
Rubocop rules, or when we update Rubocop, Pronto doesn't check whether
those rules are applied in every Ruby and ERB file, and we sometimes
forget to do so (particularly in ERB files).
So, from now, the linters will check all the code in every pull request.
Note we're now excluding the `vendor` folder in our linters because the
`setup-ruby` action actions generates a `vendor/bundle/` folder with all
our gem dependencies, and we don't want to check those files.
We're excluding these files because they use `raw` to render content
than only administrators can edit, and we trust administrators not to
provide unsafe HTML. We should definitely sanitize them at some point
but, at the same time, we should also try to keep compatibility in
installations taking advantage of `raw`.
Also note that ERB Lint does not allow customizing the severity of a
linter; if it ever does, we'll use the severity rule instead of
excluding files.
Bumps [rubocop-rails](https://github.com/rubocop/rubocop-rails) from 2.20.2 to 2.21.2.
- [Release notes](https://github.com/rubocop/rubocop-rails/releases)
- [Changelog](https://github.com/rubocop/rubocop-rails/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rubocop/rubocop-rails/compare/v2.20.2...v2.21.2)
---
updated-dependencies:
- dependency-name: rubocop-rails
dependency-type: direct:development
update-type: version-update:semver-minor
...
Note version 2.21.0 relaxes the default `Include` path for
`Rails/FindEach`, and so this version can find and correct offenses
outside the `app/models/` folder [1].
Also note this version replaces `unless something.include?` with `if
something.exclude?`; since we don't use the `exclude?` method anywhere,
we're removing the `include?` method from the list of methods checked by
this cop.
Finally, the Rails/HttpStatus method now returns a false positive when
rendering a dashboard partial and passing the `status` variable. In
order to avoid this issue, we could change the name of the local
variable or move the partial to a component, but for now we're simply
excluding these files for this cop.
[1] https://github.com/rubocop/rubocop-rails/pull/1059/commits/0066b3505
Signed-off-by: dependabot[bot] <support@github.com>
I thought SelfClosingTag was enabled since it was on the list and the
`enabled: false` got lost among all the `enabled: true`. ERB Lint 0.1
and later will also add RequireInputAutocomplete as a default linter,
and we're not interested in it, at least for now.
So, just like we do for Rubocop, we're disabling all linters and
enabling the ones we use explicitly.
We were doing it manually, but Capybara offers an option which does the
exact same thing.
This way we also apply the NoJavascriptTagHelper ERB rule, which
reported one error in the `disable_animations_in_tests` partial.
So now we remove duplication between .rubocop.yml and the rubocop rules
defined for erblint. Having the rules in two places led to some
mistakes, like renaming Layout/Tab to Layout/IndentationStyle in
`.rubocop.yml` but forgetting to do so in `.erb-lint.yml`.
This also means we can use the EnforcedStyle options for
Layout/SpaceInsideHashLiteralBraces in views as well.
We couldn't implement this feature earlier because it required Ruby 2.4
and due to incompatibilities between versions of erb_lint and versions
of rubocop.
There are some rules which do not apply to ERB files and so we're
disabling them.
* Layout/LineLength, Layout/TrailingEmptyLines and Lint/UselssAssignment
generate false positives
* Rails/OutputSafety is redundant since its functionality is already
covered by ERB Lint ErbSafety linter
Note this rule does still allow us to add new lines after opening tags;
it just makes sure that if we do, we also add it in closing tags.
Likewise, if we don't add it in the opening tag, it forces us not to add
it in the closing tag either.
I don't have a strong preference about either style; in these cases I've
chosen the latter because it seemed more common in our code.
This way we make sure we won't add `html_safe` or `raw` calls in the
future.
I'm excluding `text_with_links_helpers` for this check, because in this
situation the use of `html_safe` is justified: we check the original
input is safe, and we're only adding link tags to raw URLs.
