Oxlint JS 플러그인 알파

• 

  overlookmotelCore

• 

  CameronCore

Oxlint용 JavaScript 플러그인이 알파에 도달했습니다. ESLint 사용자의 약 80%는 이제 Oxlint로 바꿔도 "그냥 동작"할 것으로 봅니다.

Oxlint는 이미 Rust로 구현된 650개가 넘는 인기 린트 규칙을 네이티브 속도로 실행합니다. JS 플러그인은 빈틈을 메웁니다 — ESLint 호환 플러그인 API로 기존 ESLint 플러그인과 직접 만든 규칙을 Oxlint 안에서 모두 실행합니다. 대부분의 규칙은 네이티브 성능, 나머지는 완전한 유연성입니다.

작년 첫 기술 프리뷰 이후 ESLint 플러그인 API 거의 전체를 채웠고, TypeScript 플러그인, 자동 수정, IDE 연동, 큰 성능 향상을 더했습니다.

많은 팀이 린트 규칙을 다시 짜지 않고 ESLint를 Oxlint로 바꿀 수 있습니다.

이 알파는 JS 플러그인을 실제 프로젝트에서 채택할 준비가 되었다고 보는 시점입니다.

대부분의 프로젝트는 마이그레이션이 단순하고 린트 시간이 크게 줄어드는, ESLint 대체로 Oxlint를 그대로 쓸 수 있을 것입니다.

기능

• 수정 없이 대부분의 기존 ESLint 플러그인 실행
• JavaScript 또는 TypeScript로 커스텀 린트 규칙 작성
• JS 플러그인 규칙의 자동 수정·제안
• 언어 서버로 IDE에서 JS 플러그인 진단 실시간 표시

얼마나 믿을 수 있나요?

Oxlint JS 플러그인은 ESLint 자체 전체 테스트 스위트와, 널리 쓰이는 여러 ESLint 플러그인에 대해 검증합니다.

Plugin	Tests	Pass rate
ESLint built-in rules	33,006	100%
React hooks (including React Compiler rules)	5,007	100%
ESLint Stylistic	18,310	99.99%
Testing Library	17,016	100%
SonarJS	3,951	99.6%*
e18e	474	100%*

* 타입 인지 규칙 제외

위 목록에 없어도 대부분 동작합니다. 아직 저희 적합성 테스트 스위트에만 포함 안 된 것입니다.

ESLint 자체 테스트가 API 전체를 덮으므로 100% 통과는 엣지 케이스와 해피 패스 모두를 커버했다는 자신감을 줍니다. 써 보시고 알려 주세요!

Oxlint는 Midjourney, Preact, Posthog, Outline, Actual 등 여러 회사·프로젝트에서 프로덕션에 쓰이고 있습니다.

아직 안 되는 것

• 프런트엔드 프레임워크 전용 파일 형식(Svelte, Vue, Angular 등)은 제한적 지원 — 올해 안에 보강 예정
• 커스텀 타입 인지 규칙 없음(TypeScript-ESLint 규칙은 타입 인지 린팅으로 이미 Oxlint에 포함)
• Windows에서 경험이 좋지 않다는 사용자 피드백. 메모리 부족은 Windows에서 알려진 이슈입니다. 대처 중이며, 가능하면 WSL에서 Oxlint 실행을 권합니다.

이 공백 메우기 진행은 추적 이슈를 참고하세요.

시작하기

개발 의존성으로 oxlint 설치:

pnpm add -D oxlint

package.json에 스크립트 추가:

package.json

{
  "scripts": {
    "lint": "oxlint"
  }
}

설정 파일 생성(또는 마이그레이션 도구 사용):

.oxlintrc.json

{
  "jsPlugins": ["eslint-plugin-testing-library"],
  "rules": {
    "testing-library/no-render-in-lifecycle": "error"
  }
}

프로젝트 린트:

pnpm run lint

ESLint에서 마이그레이션

대부분 ESLint에서 옮기기는 단순합니다.

가장 단순한 방법은 @oxlint/migrate 도구입니다.

npx @oxlint/migrate eslint.config.js

또는 migrate-oxlint skill로 코딩 에이전트에게 맡길 수 있습니다.

자세히는 마이그레이션 가이드를 참고하세요.

ESLint 규칙

Oxlint는 ESLint 내장 규칙 대부분을 Rust로 네이티브 구현했지만 아직 전부는 아닙니다.

이 간극을 메우기 위해 oxlint-plugin-eslint로 ESLint 내장 규칙 전체를 Oxlint JS 플러그인으로 묶었습니다.

아직 Oxlint에 네이티브로 없는 no-restricted-syntax 같은 규칙을 쓸 수 있습니다.

.oxlintrc.json

{
  "jsPlugins": ["oxlint-plugin-eslint"],
  "rules": {
    // 참고: "eslint-js"이지 "eslint"가 아님
    "eslint-js/no-restricted-syntax": [
      "error",
      {
        "selector": "ThrowStatement > CallExpression[callee.name=/Error$/]",
        "message": "Use `new` keyword when throwing an `Error`.",
      },
    ],
  },
}

Oxlint는 eslint-plugin-jsdoc 등 일부 플러그인 규칙을 네이티브로도 구현합니다. 네이티브에 없는 규칙은 eslint-plugin-jsdoc 패키지를 직접 쓰는 패턴을 권합니다.

.oxlintrc.json

{
  "jsPlugins": [
    // 플러그인 별칭 "jsdoc-js" 설정
    { "name": "jsdoc-js", "specifier": "eslint-plugin-jsdoc" },
  ],
  "rules": {
    // 별칭으로 플러그인 규칙 참조
    "jsdoc-js/check-examples": "error",
    "jsdoc-js/require-description": "error",
    // Oxlint가 네이티브로 구현한 규칙은 그냥 "jsdoc"
    "jsdoc/require-property-name": "error",
    "jsdoc/require-property-description": "error",
  },
}

Performance

첫 프리뷰 이후 JS 플러그인을 돌리는 코드 상당 부분을 "Rust화"해 크게 빨라졌습니다. 특히 토큰 API에 의존하는 플러그인(예: ESLint Stylistic)은 이전 대비 최대 5배 빠릅니다.

벤치마크로 Node.js 저장소를 ESLint에서 Oxlint로 옮겼습니다. Node.js는 커스텀 린트 규칙과 무거운 ESLint 플러그인을 여럿 쓰는 대형 프로젝트입니다(JS 린트 규칙 98개).

Linter	Time	Speed-up
ESLint	1 minute, 43 seconds
Oxlint	21 seconds	4.8x

상세

INFO

• 벤치 저장소

• 6298개 파일 린트

• 104개 Oxlint 내장 규칙(Rust)

• 75개 JS 플러그인 규칙(JS)

• 23개 커스텀 규칙(JS)

• Mac Mini M4, 48GB RAM, Node.js 24.14.0에서 측정

• ESLint 벤치:

git checkout bench-eslint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run eslint"

• Oxlint 벤치:

git checkout bench-oxlint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run oxlint"

TypeScript-ESLint나 eslint-plugin-import를 쓰는 프로젝트는 훨씬 큰 이득을 볼 가능성이 큽니다. Discord 사용자 중에는 ESLint에서 Oxlint로 바꾸며 200만 줄 규모 회사 코드베이스에서 JS 플러그인을 적극 쓰는 환경에서 16배 빨라졌다고 한 경우도 있습니다. JS 플러그인을 덜 쓰는 프로젝트는 최대 100배까지 보고된 사례도 있습니다.

향후 성능 개선

시작에 불과합니다!

JS 플러그인을 쓴 Oxlint도 이미 ESLint보다 훨씬 빠르지만, 파이프라인에 둘 최적화가 많이 남아 있습니다.

Oxlint JS 플러그인 성능의 핵심은 Rust와 JS 사이 통신용 새로운 고도로 최적화된 저수준 메커니즘인 "raw transfer"입니다.

네이티브 도구가 JS 플러그인을 지원할 때 항상 문제였던 것이 Rust/JS 경계입니다. 네이티브는 빠른데 데이터를 오가는 비용이 너무 커 이득이 상쇄되며 전체 성능이 그저 그렇게 되기 쉽습니다.

Raw transfer는 데이터 이동 비용을 거의 0에 가깝게 줄여, 네이티브 코드와 JS 플러그인이 제대로 함께 쓰이게 합니다.

첫 세대 raw transfer는 이미 Oxlint 밑에서 돌아가고 있지만, 활용은 이제 시작입니다. 작업을 이어 가면 성능이 한 단계 더 도약해 JS 플러그인이 네이티브 Rust에 가까워질 것으로 봅니다.

관심 있다면 Oxc 코어 멤버 @overlookmotel의 ViteConf 2025 강연을 참고하세요.

요약: Oxlint는 이미 존재하는 가장 빠른 JS/TS 린터입니다. 앞으로 더 빨라집니다.

성능 팁 1: 포매터 쓰기

가능하면 린터로 코드 스타일을 맞추지 말고 Oxfmt(또는 선호하는 포매터)로 옮길 것을 강하게 권합니다.

Oxfmt는 Prettier보다 30배 빠르고, ESLint Stylistic 같은 린터 플러그인 대비 린트 시간도 크게 줄입니다.

Oxlint와 Oxfmt는 강력한 조합입니다!

성능 팁 2: 플러그인을 가려 쓰기

많이 믿는 것과 달리 매우 빠른 JavaScript 코드 작성은 충분히 가능합니다. Oxlint가 빠른 이유는 Rust만이 아니라 성능을 염두에 둔 설계 때문이기도 합니다.

JS 플러그인 코드 자체는 Oxlint가 통제할 수 없습니다. 전체적으로 좋은 성능을 내려면 선택한 JS 플러그인도 잘 돌아가야 합니다.

플러그인이 비효율 알고리즘이나 파일 시스템 I/O를 많이 하면 ESLint에서도 느리고 Oxlint에서도 느립니다. Oxlint가 할 수 있는 일은 번개처럼 빠른 파서와 플러그인이 쓸 수 있는 빠른 API를 제공하는 것이지, 느린 JS를 마법처럼 빠르게 만들지는 못합니다.

향후 린트가 기대만큼 빠르지 않을 때 병목이 되는 플러그인·규칙을 진단하는 유틸리티를 제공할 예정입니다.

커스텀 플러그인 만들기

프로젝트에 특수 요구가 있으면 Oxlint용 커스텀 JS 플러그인은 간단히 만들 수 있습니다.

JS 플러그인 가이드를 참고하세요.

FAQ

Oxlint가 ESLint 플러그인을 실행할 수 있나요? 네. 대부분 수정 없이 동작합니다.

Oxlint가 ESLint보다 빠른가요? 네. 벤치마크에서는 보통 4배~100배 수준의 향상이 나옵니다.

점진적 마이그레이션이 가능한가요? 네. Oxlint와 ESLint를 같이 실행할 수 있습니다.

감사의 말

JS 플러그인을 이 이정표까지 끌어올린 데 많은 분이 함께했습니다. 특히:

• @Sysix — 언어 서버 연동
• @lilnasy — API 다수 구현

커뮤니티

Oxlint JS 플러그인에 대한 피드백을 기다리며, 개발 워크플로에 어떤 도움이 되는지 듣고 싶습니다.

연락처:

• Discord: 커뮤니티 서버
• GitHub: Discussions
• Issues: oxlint 버그는 oxc로 보고해 주세요.