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
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.
- 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.
- 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.
- 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.
We will need to following linters added to each RubyOnRails project.
We will cover the installation of the linters specific to Ruby on Rails project here.
Add rubocop to the Gemfile
Run the following command to install coffeelint and stylelint
As we have three places identified where linters can work, we will cover the setup for all these places.
Right now, we have identified plugins for the VsCode editor. Other editors we will have to find.
Add the following to
.git/hooks/pre-commit inside the project directory
Create the following file
.github/workflows/linters.yml inside the project directory to setup GitHub action
- 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.
- 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 Changedtab. If we use
github-pr-reviewit 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.