株式会社RevComm の技術ブログ

全190件

2026/09/11

Rust製Linterの速さに惹かれたけど、Vueと向き合いESLintのままにした話

はじめに 1. 注目した次世代ツールの魅力 1.1 Oxlint ── 「今すぐ、設定ゼロで爆速化」 1.2 Biome ── 「これ 1 つで全てが片付く、究極の一本化」 1.3 Deno ── 「セットアップ不要、最高にクリーンな開発体験」 1.4 Ezno ── 「型チェックまで Rust 化する、超未来のコンパイラ」 2. Vue特有の壁：の静的解析問題 3. チームでの議論：「設定ファイル2つは本当に必要か？」 4. 結果 5. 今後の展望まとめはじめにフロントエンドエンジニアをしている伊藤と申します。昨今は、Rust 製のツールが数多く生み出されており、Linter もその波に乗っていると思います。弊社でも移行をしたブログを書いており、是非下記の記事も読んでみてください。 https://tech.revcomm.co.jp/ai-lint-formatter-oxc 史上稀に見る大波が来ている時代に、私も颯爽と波に乗ろうとしました。そしてどういった結論に至ったかご紹介させていただきます。注: 本記事の検証は2026年9月10日時点、Oxlint v1.82.0 / Biome v2.5.12 で行っています。この領域は変化が速いため、お読みいただく時点では状況が変わっている可能性があります。 1. 注目した次世代ツールの魅力 1.1 Oxlint ── 「今すぐ、設定ゼロで爆速化」最大の魅力：既存のプロジェクトにノーリスクで追加できるメリット ESLint の 50〜100 倍高速：数万行のコードも一瞬でスキャンが終わります。設定ファイルが不要：インストールして実行するだけで、プロ級のバグ検出ルールが最初から動きます。既存の ESLint と併用可能：重い処理（バグチェック）は Oxlint に任せ、複雑なカスタムルールだけ ESLint に残す「いいとこ取り」ができます。 1.2 Biome ── 「これ 1 つで全てが片付く、究極の一本化」最大の魅力：Linter と Formatter が融合したオールインワン構造メリット ESLint と Prettier の多くの用途を一本化できる：個別にプラグインを組み合わせる煩わしさから解放されます（ただし後述の通り、Vue の <template> 部分は現状 ESLint との併用が前提になる場面が残っています）。設定の衝突ゼロ： Linter と Formatter が同じ思想で作られているため、「Linter と Prettier のルールがバッティングして動かない」という定番のストレスがありません。圧倒的な構文解析の正確さ：エラーがあっても壊れたコードを器用にパースし、親切なエラーメッセージを出してくれます。 1.3 Deno ── 「セットアップ不要、最高にクリーンな開発体験」最大の魅力：最初からすべてが揃っている「環境」そのものメリット：ツール選定やインストールの手間がゼロ： deno lint と deno fmt が最初から内蔵されています。 package.json に大量の依存関係を書く必要がありません。標準で Web 標準に準拠：ブラウザと同じ API をそのままサポートしているため、環境ごとの差異に悩まされません。 Node.js との互換性も強力：近年は Node.js のパッケージもそのまま動くため、敷居が非常に低くなっています。注意: Deno は Linter 単体のツールではなく、ランタイムとツールチェーンそのものです。既存の Node.js プロジェクトに deno lint だけを差し込むのではなく実行環境ごと移行する話になるため、Oxlint / Biome / Ezno とは比較の土俵・移行規模が異なる点に注意してください。 1.4 Ezno ── 「型チェックまで Rust 化する、超未来のコンパイラ」最大の魅力：JavaScript の限界を超える、圧倒的に賢く高速な型解析メリット： TypeScript（tsc）より遥かに高速：現在、フロントエンド開発で一番時間がかかる「型チェック」のプロセスを Rust で爆速にします。型推論がスマート：コードの型をより深く、正確に推論してくれるため、開発者が型定義を細かく書く手間を減らせます。バグを未然に防ぐ先進性：副作用（Side Effects）の検知など、従来の TypeScript よりもさらに一歩進んだ安全なコード検証が可能です。注意: ただし Ezno は本記事執筆時点（2026年9月）でまだ feature-complete ではなく、tsc との完全互換を目指しているわけでもありません。既存の大規模プロジェクトの型チェックをそのまま置き換えられる段階ではなく、将来性に注目したい実験的プロジェクトという位置付けです。どれも高速性を売りにしており、React では非常に乗り換えやすく恩恵も受けられます！実際に私もローカルでBiomeの設定を試してみましたが、かなり早かったです。ではそのまま導入して、Rust の恩恵を受けようとしました。ただ、Vue になると少し話が変わってくるんです・・・ 2. Vue特有の壁：の静的解析問題 Vue は、HTML5 の標準仕様である <template> を、独自の便利な形に拡張して使っています。要素に v-if や v-for を付けたり、 <template> を .vue ファイルの枠組みとして使ったりしています。普段の開発をしている中で、 v-if や v-for を使わないケースはほぼないと思います。当然ですが、それらの値もチェックしてくれると思っていました。ただ、 <template> 内は、Oxlint, Biome ともにチェックしてくれないんです。実際に最新版（Oxlint v1.82.0 / Biome v2.5.12、2026年9月時点）で試した結果を、以下のサンプルコードとあわせてご紹介します。 <template > < div >  < p > {{ userNema }} </ p >  < p > {{ unusedMessage }} </ p > </ div > < / template> <script setup lang="ts"> import { ref } from 'vue' const userMessage = ref ( 'こんにちは' ) // 🔴 <script> 内は見ているので、「定義したのに使われていない！」と怒られる // （実際には上の template で使いたいのに、Linterが template を読めないせいで孤立する） const unusedMessage = ref ( 'これはエラーになります' ) < / s cript> Oxlint（v1.82.0）デフォルトでも vue-plugin オプションを付けても、このサンプルに対しては何も警告を出しませんでした。 userNema のタイポも unusedMessage の誤検知も発生しない代わりに、テンプレート側の静的解析自体がまだ行われていない、というのが実態でした。 Biome（v2.5.12）デフォルト設定ではスクリプト側の noUnusedVariables ルールが .vue ファイルにも適用され、 userMessage・unusedMessage の両方を「未使用」としてエラーにします( unusedMessage は実際にはテンプレート側で使われているので、これは誤検知です)。ただし html.experimentalFullSupportEnabled を有効にすると、Biomeはテンプレート内での参照を認識できるようになり、 unusedMessage の誤検知は解消されました(本当に未使用な userMessage は引き続き正しく検出されます)。一方で、フラグを有効にしてもテンプレート内の userNema のようなタイポを検出するルールはまだ無く、不正な変数参照を見逃す問題は解消されません。上記の検証からわかる通り、テンプレート内の静的解析はRust製Linter単体ではまだ完結できません。Biomeは実験的フラグ付きで一部の誤検知を解消できるようになってきていますが、テンプレート内のタイポ検出のような踏み込んだチェックまでは、依然として eslint-plugin-vue に頼る必要があります。つまり、必要なVue固有のルールと各ツールの対応状況次第では、OxlintまたはBiomeとESLintを併用する必要があるということです。 3. チームでの議論：「設定ファイル2つは本当に必要か？」 Rust製Linter を導入するか、一旦は ESLint のままにするか。どちらを選択するか検討するため、メリット・デメリットを出してみました。メリット圧倒的な高速化：従来のJavaScriptなどで書かれたLinter（ESLintなど）に比べ、数倍〜数十倍高速に動作します。大規模なコードベースでもミリ秒単位で処理が終わるため、CI/CDの実行時間を大幅に短縮し、開発者の待ち時間をほぼゼロにします。開発の快適化：保存時の自動整形や pre-commit フックでの実行が劇的に速くなります。簡単な導入： Rust製ツールはコンパイル済みのシングルバイナリとして配布されることが多いため、環境構築やCIでのセットアップが非常にシンプルになります。デメリット二重管理：（一番の懸念） Rust製フロントエンドLinter（BiomeやOxcなど）は、 .vue ファイルの構文（HTMLテンプレートやVue固有の構文ルール）を完全にサポートしていません。そのため、Vue固有のルール（ vue/valid-template-root など）をチェックするには、結局従来の ESLint（eslint-plugin-vue）を残さなければならなくなります TypeScript/JavaScript部分：爆速のRust製Linter（Biomeなど）でチェック Vueファイル・テンプレート部分：従来のESLintでチェックプラグインエコシステムの未熟さ：歴史のあるESLintなどのように、コミュニティが作った無数のサードパーティ製プラグインを自由に追加することが難しい場合があります。独自のルールを追加したい場合のハードルが高めです。ルールや構文の追従ラグ：言語（特にJavaScript/TypeScriptやPython）の新機能や新しい構文が登場した際、Rust側でのパーサ（構文解析器）の対応にわずかなタイムラグが生じることがあります。 4. 結果結果は、デメリット部分の二重管理の懸念部分が大きく、現状のESLint（eslint-plugin-vue）で管理する方を選びました。手元の計測で速度については、申し分ないことが立証済みでした。導入するメリットも大いに感じているものの、2つのLinterを併用する点を上回るほどではないと判断しました。 5. 今後の展望 Biome は既に html.experimentalFullSupportEnabled フラグで Vue SFC の実験的サポートを始めており、Oxlint も vue-plugin オプションなどVue向けの機能を増やしてきています。「サポートされるのを待つ」というよりも、「実験的サポートがどこまで安定するか・テンプレート内のタイポ検出のような踏み込んだチェックまでカバーされるか」を継続的にウォッチしていく、というのが今の立ち位置です。各プロジェクトの現状を、ご紹介いたします。 Biome v2.4(2026年2月)で Vue・Svelte・Astro 対応を実験的機能からプロダクション標準に近づける取り組みが発表されました。既存のリンティングルールを強化し、HTMLライクな言語でも機能するようにする方針です。 https://biomejs.dev/ja/blog/roadmap-2026/#2026-roadmap Oxlint 公式ドキュメント上の制限の記載に、Vue も含まれており、改善してくれるはずだと思います。そして、改善のための issue があり開発が進められているのがわかります。 https://github.com/oxc-project/oxc/issues/23207 https://oxc.rs/compatibility.html そしてなんといっても、Oxlint の開発を支援しているのが Vue の開発者である Evan You さんが立ち上げた VoidZero という会社なんです。現在のフロントエンドの「ツールの断片化（Linter、Formatter、テストツール、ビルドツールがバラバラで設定が面倒かつ遅い）」という課題を根本から解決するためVite+（ヴィートプラス）が開発され、その中に Oxlint も含まれています。 Vue の開発者が、Vue を見放すはずがないんです！弊社が Oxlint にするのも近いですね！まとめ Rust 製のツールは非常に高速で、すぐにでも乗り換えたいと思ってしまいます。ただ、メリット・デメリットや今後の展望を踏まえて、検討するのが大事だなと今回の移行作業を通じて感じました。どのツールにするかもしっかり検討したいです。 AI で開発を行うと、簡単に実行できるため、検討するのをサボりがちになってしまいます。そういう意味でも今回はいい勉強になったと思います。お読みいただきありがとうございました。次は、Oxlint に移行した話でお会いしましょう。

JavaScript, Node.js, TypeScript, HTML, React, Rust, フロントエンド, テスト

株式会社RevComm の技術ブログ

コンテンツ