ESLint rule changes and testing

Overview

This is an initial process to test and deploy new rules for ESLint in the vets-website repo.

Objective

To improve code quality in the repo by enforcing new ESLint rules.

Background

We installed ESLint a couple of years ago in the vets-website repo and hasn't been updated nor improved since then.

The VA.gov Platform has been reviewing all Veteran-facing Services Application (VSA) teams' Pull Requests (PRs) on vets-website. Because of the limited nature of the PR reviews Platform engineers can give, one of the main types of feedback we have been able to give concerned code quality.

Because the Platform is moving away from reviewing all VSA PRs, we plan to better leverage ESLint to automate that code quality feedback.

Specifics

Adding new rules

The ESLint rules in CircleCI will be used as an experimental staging area as we explore new rules and ways to communicate any issues that are discovered.

Part of the process for CircleCI is to run tasks against the code. There are 2 tasks that include ESLint in the workflow. One of these tasks (test_and_build) runs the rules which are enforced and the other task (additional-linting) runs the rules which are experimental. additional-linting will display all the errors related with the ESLint rules being tested, but it won't block the PR from being merged.

Code location

ESLint main file

.eslintrc => located at the root folder.

ESLint testing file

circle.eslint.json => rules under review will be located here

Plugin / new rules audit

Before adding a new plugin or new rules, it is important to perform an audit. This audit will help us determine if the current repo is in compliance with each new rule.

After doing a local audit for each rule, we could determine the state of that rule and see how many errors will produce before the rule is added to the experimental stage. All outstanding errors from each rule must be cleared (disabled or fixed) before going into the testing stage.

VFS teams are responsible for fixing the errors generated by the rule under review. Once all the errors have been cleared, we can proceed by adding the rule(s) to the testing stage file (circle.eslint.json)

Rules acceptance

All rules under review will always be considered to become enforced. However, based on feedback or complexity they can become disabled and not enforced.

Rule's lifecycle

1. Rule X is considered.

2. Rule X is added to the unenforced ruleset.

3. Rule X is test run in the unenforced ruleset for two weeks (sprint).

4. Rule X is added to the enforced ruleset.

   • Unless there are unresolved errors.

   • Unless there has been significant pushback against the rule and VSP decides to not enforce it.

Feedback

VFS engineers are encouraged to provide feedback from any rule that is under review. To do so, please use the tag @frontend-review-group or message any of the front-end tools team members in Slack and provide us with your feedback.

Help and feedback

• Suggest content changes to this page.

• Submit new Platform Website content.

• Get help from the Platform Support Team in Slack.

• Submit a feature idea to the Platform.