mcpField
O
oxlint

oxlint

github.com/dobroslavradosavljevicTesting & quality347 installsUpdated 2d ago
Repository

About oxlint

A workflow skill for development work involving Oxlint or Oxc, including configuration, rules, migration, editors, and CI. It emphasizes inspecting the repository first, consulting focused guides, and verifying changes with project-owned commands.

Key features

  1. 01Inspect versions, config, and ESLint setup
  2. 02Guidance for CLI, config, and rule choices
  3. 03Type-aware linting and plugin considerations
  4. 04ESLint coexistence and migration support
  5. 05Verify lint results with project commands

Use cases

  1. 01Configure or adjust Oxlint in an existing repository
  2. 02Troubleshoot rules, plugins, or type-aware linting
  3. 03Plan ESLint and Oxlint coexistence or migration
  4. 04Verify editor settings or CI lint changes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/dobroslavradosavljevic/skills --skill oxlint

After installing, type/oxlintin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/
openai.yaml
references/
eslint-ci-editors.md
rules-plugins-typeaware.md
setup-cli-config.md
source-map.md
usage-guide.md

Details

From the project README

Oxlint

Use this skill when work touches Oxlint or Oxc linting: install/config, day-to-day usage, rules/plugins, React Compiler lint rules, type-aware linting, ESLint coexistence or migration, editors, or CI.

Workflow

  1. Inspect the local Oxlint surface before changing code:
    • Package versions for oxlint, optional oxlint-tsgolint, eslint-plugin-oxlint, @oxlint/migrate.
    • Config: prefer oxlint.config.ts / .mts with defineConfig; also accept .oxlintrc.json(c) (one type per directory).
    • Remaining ESLint setup, ignore files, scripts (lint / lint:fix), and editor Oxc settings.
    • Whether type-aware linting, JS plugins, or React Compiler rules are in play.
  2. For setup, how-to, progressive adoption, diagnostics loops, baselines, or troubleshooting, follow the full guide first: usage-guide.md.
  3. Refresh current official docs when versions differ from the snapshot or the work touches type-aware, JS plugins, React Compiler, or migration. Start from source-map.md.
  4. Route deeper detail to the focused references:
  5. Preserve the repository's existing lint severity and plugin choices unless the user asks to migrate or expand coverage.
  6. Verify with the narrowest useful bunx oxlint / bun run lint invocation.

Core Judgment

  • Default Oxlint enables only the correctness category. Turn on other categories and plugins deliberately.
  • Setting plugins: [...] replaces the default plugin set. Re-list eslint, typescript, unicorn, and oxc when you still want them.
  • Prefer oxlint.config.ts + defineConfig for new configs (typed, shareable via imports). Keep or use .oxlintrc.json only when the project already has it, or when using a standalone binary without a Node runtime. CLI help still labels JS/TS config loading as experimental; official config docs treat oxlint.config.ts as first-class.
  • Nested configs do not auto-merge with parents — use extends (TS: imported objects; JSON: relative paths). -c/--config disables nested lookup.
  • Vite+ (vp lint, Vite+ 1.0 pins a specific Oxlint) reads the lint block in vite.config.*; nested configs are always off in Vite+ mode (1.85+), so use root lint.overrides.
  • Prefer ignorePatterns in config over scattered ignore files for editor/CI consistency. .gitignore applies to walk discovery; an explicitly named file is still linted.
  • Prefer oxlint-disable* comments long-term; eslint-disable* still works while migrating (respectEslintDisableDirectives default true).
  • Type-aware linting needs oxlint-tsgolint + --type-aware / options.typeAware. Those options are root-only. Do not pass --tsconfig together with type-aware.
  • Keep oxlint and eslint-plugin-oxlint on the same minor. Put oxlint flat configs last in ESLint so they disable overlapping rules.
  • JS plugins (jsPlugins) are alpha and outside normal semver — avoid unless required.
  • React Compiler lint rules are experimental. Since 1.79 they are per-category react/* rules (not react/react-compiler). Enabling the react plugin with default correctness turns on the recommended compiler rules. Remove any leftover react/react-compiler entry.
  • Vue/Svelte/Astro/Angular: Oxlint covers script blocks only, not templates.
  • Do not treat Oxlint as a formatter. Formatting belongs in a separate formatter tool (for example Oxfmt or Prettier).

Verification

Prefer repository-owned commands. For meaningful Oxlint work, cover the relevant subset:

  • bunx oxlint (or project lint script) on changed paths.
  • bunx oxlint --fix when autofixes are expected; review remaining diagnostics.
  • Type-aware: bunx oxlint --type-aware after dependents are built so .d.ts exist.
  • CI-shaped run with --deny-warnings or --max-warnings when those gates are project policy.
  • After ESLint coexistence changes: run oxlint && eslint and confirm no duplicate rule noise.
  • Editor/LSP smoke when changing Oxc extension settings or options.typeAware.
  • After enabling the react plugin on 1.79+: confirm whether experimental compiler rules should stay on.

Report which checks ran, which did not, and any package-version, React Compiler, or type-aware assumptions that remain.

Comments

Markdown supported