Designing Safe Autofixes for eslint-plugin-typefest
Autofix is one of the biggest quality-of-life features in ESLint, but it is also one of the fastest ways to damage trust if a rule gets it wrong.
In this plugin, a fix is not accepted just because it is convenient. A fix must be safe.
The safety barโ
Before a fixer is enabled, the rule needs confidence in three areas:
- Semantic stability: The rewritten code must keep the same runtime meaning.
- Syntactic stability: The output must stay valid TypeScript in real files.
- Formatting stability: The change should cooperate with normal formatter and linter workflows.
If any of those checks are uncertain, we downgrade to a suggestion.
Fix versus suggestionโ
Use fix whenโ
- the transformation is deterministic,
- there are no ambiguous symbols or scope collisions,
- and the replacement can be generated from source text without structural guesswork.
Use suggest whenโ
- there is a meaningful chance of behavior change,
- user intent cannot be derived from syntax alone,
- or code style constraints vary across teams.
This keeps automation helpful without becoming risky.
Why this matters in TypeScript-heavy codebasesโ
TypeScript projects frequently rely on utility types, narrowings, and overloaded APIs. Small rewrites can accidentally change constraints or type inference behavior.
A conservative strategy means developers still get guidance and one-click migrations, but only in places where the rule can prove safety.
Practical rollout adviceโ
If your team is adopting this plugin:
- Start with a baseline preset.
- Enable autofix in CI only after reviewing suggestion quality.
- Move stricter rules from suggestion-first to fix-first once confidence is high.
That progression gives teams predictable upgrades instead of disruptive churn.