Skip to content

Migrate from ESLint

Evaluate the Oxlint-native preset by defect coverage, document gaps, and remove the old runtime only after evidence.

Treat migration as a behavior change, not a package-name replacement.

  1. Keep the existing ESLint command active while the Oxlint configuration is evaluated.
  2. Select the policy level and project contexts that match the codebase.
  3. Run both tools on representative changes and classify differences by defect class, not raw rule count.
  4. Record accepted gaps for the project.
  5. Add the tested companion quality stack for formatting, Markdown/MDX, spelling, JSON Schema, and package metadata checks.
  6. Remove ESLint only when the observed behavior and remaining gaps are acceptable.

What intentionally does not migrate

The package does not preserve every historical plugin identity. Stable native Oxlint rules take ownership where they cover the same defect. Testing Library and Playwright are exceptions: the TypeScript loaders apply their package-owned plugins automatically to canonical *.test.{ts,tsx}/ __tests__/**/*.{ts,tsx} and *.spec.ts files. Testing Library uses its DOM preset by default and React preset when React is selected; Playwright uses its recommended preset; Storybook uses its recommended story rules on *.stories.{ts,tsx}. SonarJS and regular-expression gaps remain explicit.

Start smaller when needed

Use essential for a low-noise first step, then move to recommended or strict after the initial diagnostics are resolved. Adding the AI overlay does not raise that policy level.

For the detailed project checklist and companion-tool boundaries, use the repository adoption guide.