コドモン Product Team Blog

株式会社コドモンの開発チームで運営しているブログです。エンジニアやPdMメンバーが、プロダクトや技術やチームについて発信します!

ESLint と oxlint の併用構成への移行を行いました

この記事は「コドモン Advent Calendar 2025🎄」の10日目の記事になります。

コドモンでエンジニアをしている羽馬です。

今回は、コドモンの一部フロントエンド開発において、ESLint と oxlint の併用構成への移行を行った話をします。

背景

フロントエンド開発において、コードの品質を保つためにリンターは欠かせないツールです。このプロジェクトでも ESLint を使用してコードチェックを行っていました。

そんな中、別のプロジェクトで Biome から oxlint への移行を経験する機会がありました。

oxlint は Oxc project が開発する Rust 製の高速なリンターで、公式ベンチマークによると ESLint と比較して 50~100倍高速(CPUコア数に依存)という性能を持っています。

oxc.rsoxc.rs

github.com

実際に使ってみると、その高速性を実感できたため、このプロジェクトにも水平展開することにしました。リンターの高速化により、開発体験の向上が期待できます。

移行に向けた対応

設定ファイルの移行

まずは、ESLint の設定を oxlint に移行する必要がありました。できれば自動で移行できる方法を模索していた中で、Oxc project が提供している oxlint/migrate を見つけました。

github.com

これは、ESLint の設定ファイルを解析し、oxlint の設定ファイルに変換してくれるツールです。ただし、Flat Config 形式の設定ファイルにしか対応していませんでした。

幸運なことに、過去に ESLint の設定を Flat Config 形式に移行していたため、このプラグインを利用することができました。

tech.codmon.com

# 任意のESLint設定ファイルを変換
$ npx @oxlint/migrate eslint.config.mjs

このコマンドを実行することで、ESLint の設定を oxlint 用に変換できます。

ESLint との併用設定

次に、oxlint はまだ一部の ESLint ルールセットのみをサポートしているため、現時点では ESLint と oxlint の併用構成が必要になります。

しかし、oxlint で既にサポートされているルールを確認し、ESLint 側を無効化することは骨が折れる作業です。

そこで、eslint-plugin-oxlint を利用しました。このプラグインは、oxlint がすでにサポートしているルールを ESLint で無効化するためのものです。これにより、重複するルールチェックを避けることができます。

github.com

eslint.config.mjs の設定

ESLint の設定ファイルに以下を追加します。

import oxlint from 'eslint-plugin-oxlint';

export default defineConfig([
  ...oxlint.buildFromOxlintConfigFile('./.oxlintrc.json'),
]);

oxlint.buildFromOxlintConfigFile() により、.oxlintrc.json の設定を読み込み、oxlint でサポートされているルールを ESLint 側で自動的に無効化します。

package.json のスクリプト設定

リントスクリプトを以下のように設定します。

{
  "scripts": {
    "oxlint": "(oxlint || true) && eslint './src/**/*.{js,ts,vue}'"
  }
}

この設定により、oxlint 実行後に ESLint を実行します。|| true は oxlint がエラーを検出してもスクリプトを継続するためのものです。

通常であればエラーが残り続けていることは少ないのでこのような措置は不要ですが、現時点では ESLint のエラー改修が追いついていないため、このような形で運用しています。改修に関しては段階的に進行中です。

パフォーマンス測定

移行後、実際にどれくらいのパフォーマンス改善があったのかを測定しました。

測定環境

  • 対象ファイル数: 713ファイル(src配下の.js, .ts, .vueファイル)
  • プラットフォーム: macOS (Darwin 23.6.0)
  • 測定ツール: hyperfine 1.19.0
  • 測定方法: ウォームアップ1回、各コマンド10回実行して統計値を算出

hyperfine は、公式の oxlint ベンチマークでも使用されているコマンドラインベンチマークツールです。複数回実行し、平均・標準偏差・範囲などを自動的に算出してくれます。

github.com

測定対象

以下のコマンドを測定しました。

$ hyperfine -w 1 -i \
  -n "移行前(ESLintのみ)" "npm run eslint" \
  -n "移行後(oxlint+ESLint)" "npm run oxlint" \
  -n "参考:oxlint単体" "npx oxlint src"

測定結果

Benchmark 1: 移行前(ESLintのみ)
  Time (mean ± σ):      4.040 s ±  0.286 s    [User: 6.679 s, System: 0.490 s]
  Range (min … max):    3.758 s …  4.565 s    10 runs

Benchmark 2: 移行後(oxlint+ESLint)
  Time (mean ± σ):      4.016 s ±  0.183 s    [User: 6.738 s, System: 0.550 s]
  Range (min … max):    3.855 s …  4.411 s    10 runs

Benchmark 3: 参考:oxlint単体
  Time (mean ± σ):     347.7 ms ±  23.3 ms    [User: 266.8 ms, System: 96.3 ms]
  Range (min … max):   328.2 ms … 396.4 ms    10 runs

Summary
  参考:oxlint単体 ran
   11.55 ± 0.94 times faster than 移行後(oxlint+ESLint)
   11.62 ± 1.13 times faster than 移行前(ESLintのみ)

結果を表にまとめると以下のようになります。

コマンド 平均実行時間 標準偏差 範囲
移行前(ESLintのみ) 4.040秒 ±0.286秒 3.758秒 〜 4.565秒
移行後(oxlint+ESLint) 4.016秒 ±0.183秒 3.855秒 〜 4.411秒
参考:oxlint単体 347.7ミリ秒 ±23.3ミリ秒 328.2ミリ秒 〜 396.4ミリ秒

結果の分析

測定結果から、以下のことがわかりました。

トータルの実行時間はほぼ同等

移行前後で実行時間に大きな差は見られませんでした(約4秒)。これには以下の理由が考えられます。

  • ESLint の実行時間の大部分は、起動時間、設定読み込み、ファイルパースなどのオーバーヘッドが占めている
  • eslint-plugin-oxlint により重複ルールは無効化されているものの、実際のルールチェック時間よりもオーバーヘッドの方が支配的
  • そのため、併用構成でも ESLint の処理時間はあまり削減されない

oxlint 単体の高速性

一方で、oxlint 単体では713ファイルを約0.35秒で処理しており、非常に高速です。

Found 168 warnings and 106 errors.
Finished in 32-42ms on 713 files using 11 threads.

実際の lint 処理時間は30-40ms程度で、マルチスレッド処理(11スレッド)により高速化を実現しています。

開発体験の向上

トータルの実行時間は変わらないものの、開発体験としては以下のメリットがあります。

  • oxlint が約0.35秒で基本的なエラーを検出し、開発者に即座にフィードバックできる
  • その後 ESLint が追加のチェックを行うため、重要度の高いエラーから順に確認できる
  • oxlint のルールサポートが拡大すれば、ESLint への依存を減らし、さらなる高速化が期待できる

おわりに

今回、ESLint と oxlint の併用構成への移行を行いました。

トータルの実行時間は移行前とほぼ同等でしたが、oxlint による即座のフィードバック(約0.35秒)により、開発時のエラー検出が高速化されました。特に保存時の自動リントなど、頻繁に実行されるシーンでの体感速度の向上が期待できます。

現時点では ESLint のエラー改修や CI/CD への組み込みなど、まだ取り組むべき課題が残っていますが、oxlint の高速性を活用できる土台を築くことができました。

今後、oxlint のルールサポートが拡大し ESLint への依存を減らせるようになれば、さらなる高速化が実現できると考えています。段階的にエラー改修を進めることで、oxlint の恩恵をより多くの場面で活用できるようになることを期待しています。

参考リンク