ESLint config matches zero files (broken `files` glob); enables repo-wide `import type` drift

[sroussey]

Summary

eslint.config.js has a malformed files glob, so the flat-config block matches no files and ESLint is effectively a no-op across the repo. As a side effect, the import type convention has drifted: a corrected run flags 646 violations across 381 files.

Root cause

eslint.config.js:

files: ["{packages|providers|examples}/**/*.{js,ts,tsx,mts,cts}"],

The brace group uses pipes ({a|b|c}) instead of commas. Minimatch does not brace-expand a comma-less group, so this matches a literal path segment named packages|providers|examples (which doesn't exist). Result: the only config object with files matches nothing, so every file is treated as unconfigured / ignored.

Verification: running ESLint with the corrected glob {packages,providers,examples}/**/*.{ts,tsx,mts,cts} matches 1698 source files; the existing glob matches 0.

The fix is a one-character-per-separator change:

files: ["{packages,providers,examples}/**/*.{js,ts,tsx,mts,cts}"],

Why this matters

• Repo-wide linting (including the pre-commit eslint --fix in lint-staged) has not actually been enforcing any rules on source files.
• import type usage has drifted: 381 files / 646 @typescript-eslint/consistent-type-imports violations (measured with prefer: "type-imports", fixStyle: "separate-type-imports"). The autofix is mechanical (import-statement-only).

Decision needed

Fixing the glob alone activates all the recommended rules currently spread into the config (tsPlugin.recommended, react, jsx-a11y, regexp, …) repo-wide at once, which will likely surface a large backlog of unrelated violations and break bun run lint until triaged. Options:

1. Fix glob + enable consistent-type-imports + run autofix — durable, but turns on every dormant recommended rule repo-wide (large unrelated backlog).
2. Autofix only, config untouched — apply the 381-file import-type fix as one isolated commit; drift recurs since nothing enforces it.
3. Fix glob + keep other rules explicitly off, enable only consistent-type-imports — makes ESLint actually run while changing lint policy the least; durable for import-type without the backlog. (Recommended.)
4. Just fix the glob and triage the surfaced backlog separately.

Related finding (separate issue if desired)

While verifying via turbo build-types, a pre-existing type error surfaced in @workglow/huggingface-inference — src/ai/common/HFI_TextGeneration.ts:52: OpenAICompatMessage[] is not assignable to ChatCompletionInputMessage[] because content may be null. This fails build-types for that package (and transitively workglow) and is independent of the ESLint issue. Only caught by build-types (tests transpile without type-checking).