Skip to content

chore: add ESLint to enforce the code quality standards automatically #1091

Description

@sonukapoor

Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only.

Why

The project has no linter. Dev dependencies today are @types/better-sqlite3, @types/jest, @types/node, jest, ts-jest, tsx and typescript. Style rules in the code quality standards are therefore enforced by review alone, which does not scale with outside contributions.

Prettier (#446) does not close this gap. Prettier reprints the AST with consistent whitespace and never changes code structure. Verified with Prettier 3.9.6:

// input
if (!value) return "none";
// after prettier: unchanged
if (!value) return "none";

There is no brace or curly option in Prettier at all, and this is deliberate: adding braces changes code rather than formatting it. Worse, when the line exceeds printWidth, Prettier wraps it without braces:

if (a === "x" && b === "y" && c === "z" && a.length > 10 && b.length > 20)
  return "a very long return value here indeed";

which now looks like a block but is not one. Adding a second statement at that indent runs it unconditionally.

What to do

Add ESLint with typescript-eslint, starting with a deliberately small rule set rather than a large preset:

Add lint and lint:fix scripts, and a lint step in .github/workflows/ci.yml.

Sequencing

  1. SPDX branch merges first.
  2. Prettier (chore: add Prettier for consistent code formatting #446) lands next, while nothing else is in flight.
  3. ESLint after that, configured with eslint-config-prettier so the two do not fight over formatting.

Do not bundle these. Prettier is a whole-codebase reformat and ESLint is a behaviour-adjacent auto-fix; keeping them in separate commits keeps git blame and review usable.

Scope discipline

Start narrow. A large preset on an existing 12,000-line codebase produces hundreds of violations and the temptation is to bulk-disable rules, which leaves the linter theatre rather than enforcement. Each rule added should be one whose violations we are actually willing to fix.

Run --fix and the full test suite in the same commit, and confirm the test count is unchanged. Auto-fixes should be mechanical, but no-unused-vars in particular can surface genuinely dead code that deserves a look rather than a deletion.

Closes the enforcement half of #420; #1089 is superseded by the curly rule.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

ciCI/CD pipeline and workflow issuesenhancementNew feature or requestin-houseMaintainer-handled internal work - not open for contribution

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions