You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
// inputif(!value)return"none";// after prettier: unchangedif(!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:
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.
Why
The project has no linter. Dev dependencies today are
@types/better-sqlite3,@types/jest,@types/node,jest,ts-jest,tsxandtypescript. 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:
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: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:curly: ["error", "all"]- the rule that motivated this. Auto-fixable, and it closes chore: add braces to single-line if statements in args.ts and index.ts #1089 permanently instead of once.eqeqeqno-unused-varsvia@typescript-eslint/no-unused-varsno-nested-ternaryAdd
lintandlint:fixscripts, and a lint step in.github/workflows/ci.yml.Sequencing
eslint-config-prettierso 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 blameand 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
--fixand the full test suite in the same commit, and confirm the test count is unchanged. Auto-fixes should be mechanical, butno-unused-varsin 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
curlyrule.