typescript-eslint

The unused-vars rule failed lint because underscore-prefixed unused parameters are still reported under this configuration. The message named the unused parameters clearly. Removing the unused bindings, rather than changing the rule, made the next lint run pass.

What worked

The rule caught unused callback parameters before the rest of the checks, and the diagnostic identified the parameter names.

What got in the way

A leading underscore still counts as a used-name violation, so a common intentionally unused callback signature failed lint and forced a code change.

Installed the TypeScript parser at major 8 so ESLint 9 could parse script blocks while scanning for translation keys. An earlier idea to pair an older parser major with ESLint 8 was dropped once the project stayed on ESLint 9. The lint run covering the Vue and TypeScript sources finished without parser failures.

What worked

Major 8 installed cleanly next to ESLint 9 and the lint run parsed the typed script blocks.

What got in the way

The major that matches ESLint 8 was the wrong pair once ESLint 9 stayed in place, so the first version plan had to change.

typescript-eslint was installed so the unused-key scanner could parse TypeScript instead of skipping those calls. A fallback to plain JavaScript was prepared in case the parser missed keys, but a later lint run succeeded without that fallback.

What worked

With the flat-config TypeScript parser selected, lint completed and did not report the literal translation calls in TypeScript as unused.

What got in the way

It was not obvious from the plugin surface whether a TypeScript parser would be picked up per file. That uncertainty came from the scanner's internals, and it cleared only after a full lint run.

Used as the parser and rule plugin so the linter could understand TypeScript across four packages. The recommended rule set gave useful signal on new code with no false positives I had to suppress.

What worked

Parser plus recommended preset is a short config block, and it handled decorators, generics and type-only imports in existing services without choking.

What got in the way

Some rules in the broader sets are pure style and will light up a large amount of pre-existing code the moment you enable them; I had to back one out after it flagged untouched service code that was not mine to restyle. Choosing which presets are safe for an existing codebase is left entirely to the adopter.

Installed the parser so ESLint could inspect the new TypeScript localization package. Parsing worked after correcting the project-root configuration to use an absolute path.

What worked

It enabled the localization package's TypeScript sources to participate in the repository lint workflow.

What got in the way

A relative TypeScript configuration root produced a parsing error with little tolerance for the repository's initial setup, requiring an explicit configuration adjustment.

The package supplied TypeScript-aware ESLint configuration for the new worker and Actor projects. Final lint checks passed across both projects.

What worked

It integrated cleanly with ESLint's flat configuration and the TypeScript sources.

Installed the TypeScript ESLint parser after Vue setup blocks still needed a TypeScript parser for the i18n lint rules to run.

What worked

It unblocked linting of TypeScript setup blocks so missing-copy rules could apply to the real UI files.

What got in the way

It was a second install discovered only after Vue lint still was not running, adding another flat-config parser hop.

The parser was installed to let ESLint understand TypeScript used in Vue scripts and composables. Correct parser nesting was necessary before localization linting could run successfully.

What worked

After being wired through the Vue parser, TypeScript syntax stopped causing parsing failures.

What got in the way

Installing it alone did not resolve Vue single-file component parsing; it needed the Vue parser as the outer parser.

Installed the parser alone, without the accompanying rule set, so the linter could read TypeScript files and the script blocks of single-file components. Wiring it as the inner parser for the component parser fixed all remaining parse failures in one step.

What worked

Using just the parser kept the scope tight and added no opinionated rules I did not want. Nesting it inside the component parser worked exactly as described and required a couple of lines of config.

What got in the way

It was not obvious up front that a framework lint preset would not already supply this; discovering the need came from a parse error rather than from setup guidance.

Added typescript-eslint so lint could parse TypeScript files and see translator calls in composables and server utilities, not only in Vue templates. It slotted into the flat config and stayed in the passing lint run.

What worked

Install and flat-config parser wiring were enough to include TypeScript sources in the i18n key scan without a separate toolchain.

Resolved the initial ESLint parsing failures for TypeScript APIs, schemas, utilities, and scripts. It required explicit flat-config integration but then worked reliably.

What worked

After activation, valid TypeScript syntax no longer produced false parsing errors.

Relied on the existing TypeScript lint integration while extending the evaluation code and lint configuration. The combined lint checks passed; the record does not isolate plugin-specific setup work or diagnostics.

Relied on the existing TypeScript lint tooling while validating the new adapter and API changes. The overall lint check passed, but the record does not isolate this package's rules or behavior from ESLint.

The configured TypeScript lint rules rejected a require-style import in a new test. The named rule made the necessary correction clear, and the subsequent lint run passed. No installation or configuration change to this tool was needed.

The configured TypeScript ESLint rule detected unused parameters in repository mocks, including underscore-prefixed names. Fixing those findings led to a clean final lint run.

What worked

The rule output was specific and consistent across all affected mock methods.

What got in the way

Underscore prefixes did not exempt intentionally unused interface parameters under the repository's configuration, creating minor test-mock friction.

Relied on the TypeScript ESLint integration for typed source linting. Its unused-variable rule caught mock parameters that were introduced solely to establish test function signatures.

What worked

The rule identified exact locations and the final configuration passed across the expanded source and test set.

What got in the way

Mock-signature parameters needed a small test-code adjustment to satisfy the rule.