Explore oxlint adoption

[patroza]

• how much effort
• estimated performance improvements

Concerns

• eslint codegen
• vue ? oxlint: better vue support oxc-project/oxc#15761

[patroza]

Assessment

Hard blockers for a full replacement

1. eslint-plugin-codegen — Your barrel, model, and meta codegen presets are deeply integrated. oxlint has no code generation equivalent. This is the biggest blocker.

2. Type-checked rules — no-floating-promises, no-misused-promises, unbound-method, no-unsafe-* all require TypeScript's type checker. oxlint doesn't do type-aware linting. These are critical for Effect code safety.

3. Custom rule @effect-app/no-await-effect — Your custom rule uses type information to detect awaited Effects. oxlint doesn't support custom JS rules or type-aware analysis.

4. @ben_12/dprint formatting integration — oxlint doesn't do formatting. You'd need to run dprint separately (which is fine, but changes the workflow).

5. Vue-specific rules — eslint-plugin-vue, formatjs for ICU messages. oxlint has growing Vue support but not equivalent coverage.

What oxlint CAN replace

• unused-imports (built-in)
• object-shorthand, no-restricted-imports, basic JS/TS rules
• consistent-type-imports (supported)
• no-namespace, no-empty-interface, no-explicit-any
• Some import ordering (partial)

Realistic options

Approach | Pros | Cons -- | -- | -- Hybrid: oxlint for fast rules + ESLint for codegen/type-checked/custom | Faster lint for most rules, gradual migration | Two tools to maintain, config complexity Wait | oxlint is rapidly evolving, type-aware linting is on their roadmap | No speed gains now Full replace | Not feasible today | Loses codegen, type-checking rules, custom rules

My recommendation

Don't do a full migration now. The three hard blockers — codegen presets, type-checked rules, and your custom Effect rule — are non-negotiable for this codebase. The codegen plugin alone is a showstopper since it's doing AST-based code generation that has no oxlint equivalent.

If lint speed is a concern, the best near-term move would be a hybrid setup: run oxlint for the ~15 fast rules it covers well, and keep ESLint only for codegen + type-checked rules. But honestly, the config maintenance cost of two linters may not be worth the speed gain unless lint times are actually painful.

[patroza]

Playing on libs now with it 4b91f31
Make sure to enable oxlint vs code plugin too for the repo