Date: 2024-02-26 Status: Accepted
Our frontend code currently enforces the essential
set of linting rules from eslint-plugin-vue
. This minimal set of
rules leaves a lot of code style up to individual authors and avoids enforcing a number of
community best practices. For this codebase to better support new volunteers frequently
onboarding while maintaining consistency and readability, we would benefit from adopting the full
set of Vue community recommended linting rules
(strongly recommended
and recommended).
- Consistency and readability: Enforcing style choices keeps code more readable and maintainable.
- Easy Onboarding: By adopting and automating community standards, we make it easier for new engineers to spin up and be productive quickly.
- Security: Some rules help us enforce security best practices (e.g.,
vue/no-v-html
). - Bug prevention: Some rules help us avoid bugs before they happen (e.g.,
vue/no-template-shadow
).
The relevant option space is really just which rules to adopt. The eslint-plugin-vue
package
organizes its rules into three groups (each being a superset of the previous):
- Priority A: Essential (Error Prevention) — our current ruleset
- Priority B: Strongly Recommended (Improving Readability)
- Priority C: Recommended (Potentially Dangerous Patterns) — proposed ruleset
We could also override individual rules from these rulesets if we disagreed with them or they caused undue burden in development.
This proposal is to adopt the full recommended ruleset for linting across our frontend code.
In order to avoid a "pause the world" style single giant PR, we would introduce the linting rules incrementally. Examples of how this would work can be seen in:
- Code change to introduce eslint rule change – #2654
- Example of burning down one file incrementally — #2655
The burndown work could easily be split into a number of "easy first issue" tickets and worked through over a couple weeks.