chore(eslint): enforce consistent-type-imports and apply the repo-wide autofix

[sroussey]

Closes #585

Measured reality first: most of this issue was already fixed on main

Before changing anything I re-measured every claim in the issue against origin/main. Most of it is stale:

Issue claim	Measured on main	Status
Malformed files glob (pipes instead of commas)	eslint.config.js:16 already reads files: ["{packages,providers,examples}/**/*.{ts,tsx,mts,cts}"]	Already fixed
Repo-wide lint no-op hiding a large dormant backlog	eslint reports 0 errors / 0 warnings across 2030 files	Stale — no backlog exists
Pre-existing HFI_TextGeneration.ts type error	Already coerces m.content ?? "" (line 50); build:types passes 41/41	Already fixed
import type drift	consistent-type-imports still absent; 612 violations across 380 files	Real — fixed here

The consequence is that the issue's central worry — that repairing the glob would unleash a flood of violations from the recommended rule sets and force us to disable things — does not apply. The rule sets are already clean. So the issue's "Option 3" collapses into simply add the one missing rule. No rules were disabled in this PR.

What this PR does

Two commits, so review stays sane:

1. chore(eslint): enforce consistent-type-imports — one hand edit, 1 file, +13 lines.
2. chore: apply consistent-type-imports autofix — the purely mechanical bun run format output, 380 files. No hand edits in this commit.

Measured violation counts:

• Before the autofix: 612 problems across 380 files, all from @typescript-eslint/consistent-type-imports, 100% autofixable (0 non-autofixable).
• After the autofix: 0 problems. A single --fix pass converges with zero residual messages.

Why disallowTypeAnnotations: false — measured, not assumed

The rule defaults disallowTypeAnnotations to true. I probed what that default would actually cost by running the identical config with only that flag flipped:

Setting	Total problems	Non-autofixable
disallowTypeAnnotations: false (this PR)	612	0
disallowTypeAnnotations: true (the default)	683	71 across 32 files

The 71-problem delta is entirely `import()` type annotations are forbidden. — and none of them are autofixable, so they would each need a hand edit.

Those annotations are not sloppiness; they are this repo's deliberate pattern for typing an optional peer dependency without forcing a static import that would break consumers who have not installed the package — e.g. typeof import("pg") in providers/postgres/src/storage/_postgres/browser.ts and the same shape in packages/tasks/src/task/adaptive.ts. Turning the option on would either break that pattern or bury 71 inline disables.

The config carries a comment explaining this so a later "cleanup" does not silently flip it and break the build.

consistent-type-exports was deliberately not added: it requires type-aware parsing (parserOptions.project), which this config does not set up.

Did this break an import-for-registration side effect?

This is the first thing to ask about a 380-file import type sweep, so I checked it explicitly rather than assuming. import type is erased at emit, so converting a whole import of a module that self-registers on load would silently stop the registration.

Scoping the actual risk surface:

• 612 fixes total; 320 are whole-import conversions (import { X } → import type { X }), the only ones that can elide a module.
• Of those 320, 107 use relative specifiers (a bare package specifier resolves to a package that is loaded through many other paths anyway), resolving to 47 distinct local modules.
• Of those 47, exactly 2 have import-time side effects:
  • packages/task-graph/src/task/GraphAsTask.ts — calls registerGraphWrapperFactory(...) at module scope.
  • packages/task-graph/src/task/ReduceTask.ts — a top-level queueMicrotask(...).

Both remain value-imported elsewhere, so both modules still load and their side effects still run:

• GraphAsTask went type-only in just 2 files (WorkflowBuilder.ts, GraphAsTaskRunner.ts) but is still value-imported by task/index.ts (plus export * from "./GraphAsTask"), WhileTask.ts, IteratorTask.ts, FallbackTask.ts, TaskJSON.ts, Workflow.ts, WorkflowTask.ts, WorkflowPipe.ts.
• ReduceTask is still value-imported and re-exported by task/index.ts; only its config type went type-only in TaskJSON.ts.

This should be a no-op regardless: the root tsconfig sets neither verbatimModuleSyntax nor importsNotUsedAsValues, so the compiler already elides type-only-used imports today. The full build and the integration suites below are the actual proof — the graph and task integration sections exercise both of these modules directly.

⚠️ Merge-conflict cost — please sequence this deliberately

This is a ~380-file mechanical diff that touches the import block of a large fraction of the repo. It will conflict with essentially every in-flight branch that adds, removes, or reorders an import.

This matters concretely right now: there are eight other open PRs from this same triage pass — #672, #676, #677, #678, #679, #680, #681, #682 — and several of them touch files this sweep also rewrites.

Recommended handling:

• Merge this either first or last relative to that batch — not into the middle of it.
• If merged first, branch owners should rebase and simply re-run bun run format; the rule will re-apply the same normalization to their code.
• Resolve conflicts by re-running the formatter, not by hand. Every hunk here is machine-generated; hand-merging import blocks is pure risk with no upside. On conflict, take either side, then run bun run format and commit the result.

Recommended follow-up (deliberately NOT done here)

There is a durability gap: this rule is only enforced by a bypassable hook.

• There is no lint script in the root package.json — bun run lint does not exist (the relevant script is format, which fixes rather than checks).
• No CI workflow runs ESLint. .github/workflows/test.yml runs typecheck:budget, build, and the vitest suites — no lint step.
• The only gate is .husky/pre-commit → bunx lint-staged, which any git commit --no-verify skips.

So the drift this PR cleans up can silently return. Suggested in a separate PR (kept out of this one to preserve its mechanical, conflict-resolvable-by-formatter character): add "lint": "eslint" to the root scripts and a CI step that runs it.

Verification

All commands run on this branch after the autofix.

$ ./node_modules/.bin/eslint
(no output — exit 0)

# before the autofix, with the new rule active:
#   files linted: 2030
#   total problems: 612   (all @typescript-eslint/consistent-type-imports)
#   files with problems: 380
#   autofixable: 612   NOT autofixable: 0

$ git diff --stat | tail -1
 380 files changed, 1081 insertions(+), 1134 deletions(-)

$ bun run build:types
 Tasks:    41 successful, 41 total
Cached:    0 cached, 41 total          # real rebuild, not a cache replay

$ bun run build
 Tasks:    84 successful, 84 total

$ bun run typecheck:budget             # CI gates on this
typecheck-budget: OK (38 packages within budget)

$ bun scripts/test.ts vitest unit
 Test Files  379 passed | 2 skipped (381)
      Tests  4658 passed | 47 skipped (4705)

$ bun scripts/test.ts vitest integration graph task storage queue util mcp
 Test Files  44 passed (44)
      Tests  1576 passed | 42 skipped (1618)

For reference, the pre-autofix baseline of the unit suite on this same machine was 379 passed | 2 skipped (381) / 4658 passed | 47 skipped (4705) — identical to the post-autofix result, confirming the sweep changed no runtime behavior.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PwyJuFrJnibKvrrk8Fa4Fn

---

Generated by Claude Code

[sroussey]

test-vitest-rag failed on 3576d33 for an external reason, not this diff.

Every failure in the job is an HTTP 429 from the Hugging Face Hub; there are no assertion failures:

PermanentJobError: Provider HF_TRANSFORMERS_ONNX failed for TextEmbeddingTask:
Error (429) occurred while trying to load file:
"https://huggingface.co/Xenova/all-MiniLM-L6-v2/resolve/main/config.json"

The RAG suite embeds through HF_TRANSFORMERS_ONNX, which downloads model files at test time, so the section fails whenever the Hub throttles.

Why this is not an erased import side effect — the obvious suspicion for a 380-file import type sweep. The error shows the provider was resolved and dispatched (Provider HF_TRANSFORMERS_ONNX failed for TextEmbeddingTask) and then the network call was throttled. Had registration been elided, the failure would be a missing provider/capability at lookup time, before any Hub request. Registration ran.

Contributing cause is contention: nine PRs from one triage pass (#672, #676–#683) had CI running in a short window, each pulling models from the Hub. #677 hit the identical 429 on different models (clip-vit-base-patch32, owlvit-base-patch32) in a different section, and passed cleanly on re-run.

Actions taken:

• Re-run queued for the failed job (GitHub refuses one while the run is still in progress; retried shortly).
• Separately re-running the rag section locally against this branch, since it was outside the integration list used for the original verification. Result will be reported here.

If the 429 reproduces on a clean re-run, I'll stop treating it as flaky and investigate properly rather than retrying again.

---

Generated by Claude Code

[sroussey]

Follow-up: the rag section passes on this branch, confirming the CI failure was the Hub 429 and not a regression.

$ bun scripts/test.ts rag vitest        # on 3576d33

[e2e-rag: ingest]            39.61s
[rag-wf: ingest]             43.04s
[rag-wf: qa]                 11.94s
[rag-wf: complex-pipeline]    0.35s
[hybrid-pg]                   2.22s

 Test Files  24 passed (24)
      Tests  225 passed (225)
   Duration  167.07s

The multi-second ingest phases confirm the embedding pipeline actually ran end to end — models loaded, documents chunked and embedded, retrieval exercised — rather than the suite short-circuiting.

This section sat outside the integration list used for the original verification (graph task storage queue util mcp), so it is now covered. Combined with the earlier results on this branch — eslint 0 problems, build:types 41/41 uncached, build 84/84, typecheck:budget OK, unit 4658 passed | 47 skipped byte-identical to the pre-autofix baseline, and integration 1576 passed | 42 skipped — every suite has now run green against the autofix.

The CI re-run is still queued behind the in-progress workflow.

---

Generated by Claude Code

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	64.05%	31177 / 48670
🔵	Statements	63.87%	32271 / 50525
🔵	Functions	65.24%	5877 / 9007
🔵	Branches	52.96%	16044 / 30292

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/storage/src/kv/FsFolderJsonKvStorage.ts	100%	100%	100%	100%
packages/storage/src/kv/IKvStorage.ts	100%	100%	100%	100%
packages/storage/src/kv/KvStorage.ts	40%	100%	14.28%	40%	59-84
packages/storage/src/kv/KvViaTabularStorage.ts	46.8%	61.9%	31.25%	48.88%	54-66, 78-84, 104-115, 121, 128-141
packages/storage/src/tabular/BaseTabularStorage.ts	18.55%	7.35%	10.14%	20.37%	78-117, 202, 204, 222, 225-227, 231, 243-250, 258, 260-270, 284, 287, 297-298, 304-307, 311-317, 326-327, 330, 335-912, 933-938, 958-967, 972-973, 976-977, 1000-1046, 1054-1142
packages/storage/src/tabular/FsFolderTabularStorage.ts	19.88%	7.81%	14.28%	21.21%	47-79, 119-146, 154-174, 184-191, 201-202, 221-232, 240, 244-333, 347-422
packages/storage/src/tabular/ITabularStorage.ts	9.09%	0%	0%	12.5%	183-299
providers/huggingface-transformers/src/ai/common/HFT_ImageEmbedding.ts	5%	0%	0%	5%	24-59
providers/huggingface-transformers/src/ai/common/HFT_ModelSchema.ts	100%	100%	100%	100%
providers/huggingface-transformers/src/ai/common/HFT_TextEmbedding.ts	3.57%	0%	0%	3.57%	28-102

Generated in workflow #2887 for commit 27e97cc by the Vitest Coverage Report Action

[sroussey]

Sequencing: hold this until #621 lands — measured

This PR's body asks to be merged "either first or last" relative to the triage batch. That's now decidable: last, and specifically after #621 (full-stream), which is being rebased right now.

Trial-merged every combination against origin/main at 0c90d19b:

Combination	Conflicts
#621 → current main (baseline)	0
#621 → main + #672	0
#621 → main + #677	0
#621 → main + #679	0
#621 → main + #681	0
#621 → main + #682	0
#621 → main + #683 (this PR)	5

The five:

packages/job-queue/src/job/JobQueueServer.ts
packages/job-queue/src/queue-storage/InMemoryQueueStorage.ts
packages/task-graph/src/storage/TaskOutputRepository.ts
packages/task-graph/src/task/CacheCoordinator.ts
packages/test/src/test/task-graph/StreamingBackpressure.test.ts

#621 touches 107 files, this PR 381, and they overlap on 19 — but only those 5 collide at hunk level, because most of the overlap is in files where #621's edits sit away from the import block.

So: #621 currently merges cleanly into main, and merging this PR first is the only thing in the batch that would break that. Every conflict is machine-generated import normalization, so each resolves by taking #621's side and re-running bun run format — but that's five hand-resolutions imposed on an 83-commit rebase, for no benefit, when waiting costs nothing.

Recommendation: merge #672 / #677 / #679 / #681 / #682 freely now, land #621, then merge this last and let the formatter re-normalize whatever #621 introduced. No change requested to the PR itself — it stays green and mergeable_state: clean.

---

Generated by Claude Code