oxlint

Oxlint — High-Performance JS/TS Linter

Oxlint is 50-100x faster than ESLint. It ships with 690+ rules covering ESLint core, TypeScript, React, Jest, Unicorn, jsx-a11y, and more. It prioritizes high-signal correctness checks by default — things that are incorrect, unsafe, or useless — so teams can adopt it without drowning in false positives.

Detection

Before linting, confirm the project uses oxlint by checking for any of:

• oxlint in package.json devDependencies/dependencies
• An .oxlintrc.json file in the project root
• An oxlint.config.ts file in the project root
• An oxlint or lint script in package.json that references oxlint

If none of these exist, the project doesn't use oxlint — don't run it.

Running Oxlint

After code changes

Run oxlint to check your work. Prefer the project's npm script if one exists:

# If package.json has a lint script using oxlint
npm run lint

# Otherwise, run directly
npx oxlint

Fixing issues automatically

npx oxlint --fix

Use --fix for safe automatic fixes. Avoid --fix-dangerously unless the user explicitly asks for it — it can apply unsafe transformations.

Linting specific files

After editing only a few files, you can lint just those:

npx oxlint src/components/Button.tsx src/utils/helpers.ts

Interpreting output

Oxlint prints diagnostics with rule names in parentheses, e.g. (no-unused-vars). When fixing:

1. Read the diagnostic message carefully — oxlint gives precise, actionable information
2. Fix the underlying code issue rather than suppressing the rule
3. Only add // oxlint-ignore comments as a last resort when the diagnostic is a genuine false positive

Output formats

For CI or tooling integration:

npx oxlint --format json        # Machine-readable JSON
npx oxlint --format github      # GitHub Actions annotations
npx oxlint --format unix        # Simple one-line-per-error format

Configuration

Creating a config

npx oxlint --init

This generates an .oxlintrc.json starter config.