Add minimal lint rules for code quality

[arseniy-gl]

Why

The project uses tsc --strict + pnpm guard for validation. This covers types, architecture boundaries, and design-system integrity well. But with active LLM usage in development, there is a gap: LLM-generated code often passes typecheck while containing quality issues that neither tsc nor guard catches.

Data from the codebase

Pattern	Count	What catches it today
as any / as unknown as	76	nothing
@ts-ignore / @ts-nocheck	26 files	guard (import resolution only)
Non-null assertions (!.)	13	nothing
useEffect calls without dep checking	859	nothing
Floating promises (no await/void)	present	nothing
Unused imports/locals	unknown	noUnusedLocals not enabled
Inconsistent quote style	zh-CN uses double, en uses single	nothing

Proposal

Not a full ESLint setup. Just 3-4 targeted rules that catch the most expensive LLM-specific bugs:

1. noUnusedLocals + noUnusedParameters in tsconfig — free, one line each, catches dead code from LLM refactoring
2. react-hooks/exhaustive-deps — 859 unchecked useEffect calls is the highest-risk area
3. @typescript-eslint/no-floating-promises — catches missing await on async calls
4. @typescript-eslint/no-unsafe-assignment — catches as any escapes

These could be added as a lightweight ESLint config or, for items 1, just a tsconfig change.

What this is not

• Not a request for Prettier or full code-style enforcement
• Not a replacement for guard — it covers different ground
• Not blocking any current work

[lefarcen]

Hi @arseniy-gl! The direction makes sense — this repo already leans on strict TypeScript plus targeted guard scripts, so adding a few focused checks for LLM-shaped regressions feels like a good fit.

A couple of things from the current tree stand out: there isn't a general ESLint config yet, there is already a dedicated @ts-nocheck import-resolver guard in scripts/check-ts-nocheck-imports.ts, and the repo has a lot of existing useEffect(...) / as any surface area. So this probably lands best in small slices rather than flipping all four rules on at once. A practical first pass would be either noUnusedLocals + noUnusedParameters, or a minimal lint setup scoped to one high-signal rule with an explicit rollout plan for existing violations.

I've marked this as help wanted — if you want to take a first pass PR here, we'd be happy to review it. Starting narrow will likely make this much easier to land.

[lefarcen]

Open to the community if anyone wants to take this on — comment /claim and we can route it to you for a first pass PR.

[arseniy-gl]

/claim

[lefarcen]

Hey @arseniy-gl, appreciate you picking this up. What feels realistic on your side — a few hours, 1–3 days, about a week, or longer?

[arseniy-gl]

Good call on small slices. Here's the priority order I'm thinking, each as a separate PR with fixes included:

PR 1: noUnusedLocals + noUnusedParameters (tsconfig only, no ESLint needed)
188 violations: 141 web, 45 daemon, 2 packages. Mostly dead imports and leftover variables. No new dependencies — just two tsconfig flags.

PR 2: @typescript-eslint/no-floating-promises (minimal ESLint setup)
Introduces the ESLint config itself with just this one rule. Catches missing await on async calls — real runtime bugs.

PR 3: react-hooks/exhaustive-deps
859 useEffect calls to audit. Highest impact but also most violations — makes sense to land after the ESLint infra is in place from PR 2.

PR 4: @typescript-eslint/no-unsafe-assignment
76 as any / as unknown as instances. Might need discussion on which ones are intentional.

Time estimate for PR 1: 1–2 days. Each next PR builds on the previous one's infrastructure.

Does this order make sense to you?

[lefarcen]

Hey @arseniy-gl — yes, that ordering makes sense to me.

Starting with noUnusedLocals / noUnusedParameters keeps the first PR dependency-free and should clear out a lot of noise before the ESLint-based passes. Then no-floating-promises as the first lint rule feels like the right next step, and waiting until after that for react-hooks/exhaustive-deps should make the bigger audit easier to land. Saving no-unsafe-assignment for last also seems reasonable since that one is more likely to need judgment calls on intentional escapes.

The 1–2 days estimate for PR 1 sounds realistic too. If you keep each PR narrowly scoped the way you outlined here, that should make review much smoother.

[lefarcen]

Heads-up: PR #6130 is now open as the first rollout slice for this issue. It keeps the scope daemon-only, enables noUnusedLocals in apps/daemon/tsconfig.json, and removes the dead-code violations that surfaced there.

Keeping this issue open for the remaining planned slices (no-floating-promises, react-hooks/exhaustive-deps, no-unsafe-assignment, and the wider web/package rollout).

[lefarcen]

Hey @arseniy-gl, gentle check — PR #6130 has been quiet since the blocking review from @nettee. Anything you want feedback on, or are you mid-iteration?

[lefarcen]

Hey @arseniy-gl — your rollout order still looks like the right one from here. PR #6130 confirmed that the daemon-first slice is a workable starting point; the current blocker is narrower than the overall plan: once noUnusedParameters is enabled in that daemon tsconfig pass and the PR is refreshed, this issue can stay as the umbrella for the remaining slices in the same order you proposed.

For the follow-ups, keeping the web/package noUnused* rollout separate from the ESLint-rule PRs still feels like the cleanest review path too — that keeps the dead-code cleanup distinct from the new lint-infra work.