Linter to development flow

Created

Sep 7, 2022 8:39 AM

Department

Engineering

Description

Adding linter to the development flow will help developers to write the proper and updated syntaxes. Also, it helps the Team leaders or Peer reviewers in checking the logic rather than commenting on minor syntax issues

Linter flow

There are three possible ways we have identified that we can have linter added to the development flow before the code reaches staging or production.

Editor
Git Pre-commit
GitHub actions

We will be adding linters in all three places, and these are the reasons why we need it in three places.

Editor

The developer is hinted at in the editor by the linter, But there are chances that the developer can miss these as it is a small underscore highlighting the issue.

Pre-commit

This is the mandatory step which will stop the developer to commit if there are any issues present in the code.
We will be checking only newly created files for the existing project since the old files may be big and it's not easy to fix all the issues.
We will be checking all the files for any new project that we take up.

Github action

Though most of the things are covered in the pre-commit, it is an additional step which will help the reviewers to understand the code is of good quality.
Another reason is a developer can skip the pre-commit check, but it will get displayed on the GitHub action.

Linters required

We will need to following linters added to each RubyOnRails project.

Rubocop
CoffeeLint
StyleLint
Reek

Installation

We will cover the installation of the linters specific to Ruby on Rails project here.

Add rubocop to the Gemfile

group :development do
  gem 'rubocop', '~> 1.35.1', require: false
  gem 'rubocop-rails', '~> 2.15.2', require: false
  gem 'rubocop-performance', '~> 1.14.3', require: false
end

Run the following command to install coffeelint and stylelint

npm install -g @coffeelint/cli
npm install --save-dev stylelint stylelint-config-standard-scss

Setup

As we have three places identified where linters can work, we will cover the setup for all these places.

Editor

Right now, we have identified plugins for the VsCode editor. Other editors we will have to find.

Pre-commit

Add the following to .git/hooks/pre-commit inside the project directory

#!/bin/bash

# Remove M in diff-filter if only new files are required for linting.
files=$(git diff --cached --name-only --diff-filter=AM)
files="$files $(git status -s | grep -E 'R' | awk '{print $4}')"
echo $files | xargs rubocop --display-cop-names --extra-details --parallel --force-exclusion
echo $files | xargs reek
echo $files | grep -E ".scss" | xargs npx stylelint

GitHub action

Create the following file .github/workflows/linters.yml inside the project directory to setup GitHub action

# .github/workflows/linters.yml
name: linters
on: [pull_request]

jobs:
  linters:
    name: runner / linters
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
        with:
          ruby-version: 3.0.0
      - name: rubocop
        uses: reviewdog/action-rubocop@v1
        with:
          rubocop_version: 1.30.0
          rubocop_extensions: rubocop-rails:2.14.2
          github_token: ${{ secrets.GITHUB_TOKEN }}
          reporter: github-pr-check # Possible values are github-pr-check, github-pr-review
      - name: reek
        uses: reviewdog/action-reek@v1
        with:
          reek_version: 6.1.1
      - name: runner / stylelint
        run: npx stylelint **/*.scss
      - name: coffeelint
        uses: reviewdog/action-coffeelint@v1
        with:
          reporter: github-pr-review

Note:

If you want to ignore the pre-commit and want to push certain commits to github, you can use the following option. Use it only if there is any urgency.

git commit -n -m "Commit message."

In GitHub action, we will be using the reporter option as github-pr-check , reviewdog won’t print it as a comment on PR but it will be shown under Files Changed tab. If we use github-pr-review it will point issues as comment and it would be hard to distinguish the user and bot comment, especially for old projects this will be hard.