Oxcとは？Rust製JavaScriptツールチェーンの構成と使い方・SWCとの違い

Oxc（オーエックスシー、正式名 JavaScript Oxidation Compiler）は、JavaScriptとTypeScriptを扱うツール群をRustで実装したオープンソースプロジェクトです。リンターのOxlint、フォーマッターのOxfmt、パーサー、トランスフォーマー、ミニファイア、モジュールリゾルバーを同じ基盤の上で提供しており、Vite 8のバンドラーRolldownもこの部品を使っています。この記事では、2026年10月23日時点の各ツールの版と成熟度、GitHubリポジトリの見方、Node.jsから部品を呼ぶ方法、ReactやVueでの対応範囲、VS Code拡張とAIコーディングエージェントとの連携、Vite 8での役割、SWC・Babelとの違いを扱います。コマンドの出力は node v26.5.0 で実行して取得しました。光通信の光クロスコネクト（OXC）や、コンテストサイトのOnline X Contest（OXC）は扱いません。

まとめ：Oxcの構成と使いどころの要点

• Oxcは単一のツールではなく、リンター・フォーマッター・パーサー・トランスフォーマー・ミニファイア・リゾルバー・TypeScriptランナーをまとめたプロジェクト名で、npmでは部品ごとに別パッケージです。
• 成熟度は部品ごとに違います。Oxlintは安定版の1.89.0、Oxfmtはベータの0.74.0、パーサーなどのNode APIは0.155.0で、ほぼ毎週版が上がります。
• アプリ開発者が直接触るのはOxlintとOxfmtで、VS Codeでは公式拡張 oxc.oxc-vscode を入れます。Reactのルールは既定で無効なので、プラグインを有効にします。
• Oxlint 1.66.0以降は、Claude CodeやCodexの中で実行されたことを環境変数で検知し、1件1行のエージェント向け形式で結果を出します。
• Vite 8では本番ビルドの既定ミニファイアがOxcで、意識しなくてもOxcを通っています。
• Node.jsからtypescript.js（約9.1MB）のASTを受け取るまでは、oxc-parserの experimentalRawTransfer 有効時が203ms、@babel/parserが1,063ms、oxc-parserの既定設定が1,594msで、既定のままではBabelより遅くなります。
• ESLintやPrettierのプラグインに強く依存しているなら、併用から始めます。

Oxcを構成する7つのツールと成熟度

名前の「Oxidation（酸化）」は、錆（rust）を生む化学反応にかけた命名です。公式の「What is Oxc?」は、Oxcを「RustでJavaScriptとTypeScript向けの高性能ツールを集めたもの」と定義し、VoidZero社の統合ツールチェーン構想の一部と位置づけています。VoidZeroはViteの作者Evan You氏が設立した会社で、2026年6月にCloudflareの一部になりましたが、OxcはMITライセンスのまま同じチームが開発を続けています。

各ツールの現行版と段階

段階の列は公式の表記に合わせています。公式トップはFormatterに「Beta」、Minifierに「Alpha」を付け、TypeScriptランナーのページは「experimental」と明記しています。パーサー・トランスフォーマー・ミニファイアの版が揃っているのは、Rustのクレート群と同じ crates_v0.155.0 タグで同時にリリースされるためです。0.x系なので、マイナー版の更新でもAPIが変わることがあります。

Oxcが速い理由と公式ベンチマークの読み方

公式のパーサーのアーキテクチャ解説は、速さの理由を4つ挙げています。ASTをメモリアリーナ（bumpalo）にまとめて確保し、まとめて解放すること。短い文字列をCompactStringでインライン化すること。それ以外のヒープ割り当てをしないこと。スコープの束縛やシンボルの解決を、パーサーではなく後段の意味解析に任せることです。公式サイトに転載されている性能解説（初出はRust Magazine）では、ASTをアリーナに載せ替えただけで約20%速くなったと書かれています。リンター・フォーマッター・変換は、どれもこのパーサーとASTの上に作られています。

公式のベンチマークページは、パーサーがSWCの3倍以上、トランスフォーマーがBabelの40倍、OxlintがESLintの50〜100倍、OxfmtがPrettierの35倍、リゾルバーがwebpackのenhanced-resolveの30倍としています。ただしOxfmtの紹介ページは「Prettierの約30倍」と書いており、ページによって数字がずれています。Node.jsから使ったときの実測は後半に載せました。

GitHubリポジトリoxc-project/oxcの構造とリリースの追い方

ソースは github.com/oxc-project/oxc にあります。ライセンスはMIT、リポジトリの作成は2023年2月9日、スター数は2026年10月23日時点で23,189です。ディレクトリは役割ごとに分かれていて、目的のコードを探すときは次の3つを押さえておけば足ります。

• crates/：Rustの本体です。oxc_parser・oxc_linter・oxc_transformer・oxc_minifier・oxc_formatter・oxc_isolated_declarations・oxc_react_compiler・oxc_language_server などが並びます。
• apps/：コマンドラインツールです。oxlint と oxfmt の2つがあります。
• napi/：Node.js向けのバインディングです。parser・transform・minify・transform-react などがnpmパッケージの元になります。

Releasesページには、oxlint_v1.89.0・oxfmt_v0.74.0・crates_v0.155.0 のように接頭辞付きのタグが混在します。直近は9月28日、10月5日、10月13日、10月19日と、ほぼ毎週まとめて出ています。Oxlintの更新だけを追うなら、apps/oxlint/CHANGELOG.md を見れば足ります。ドキュメントは別リポジトリの oxc-project/website にあります。

Node.jsからOxcの部品を使う方法

ビルドツールや独自のコード解析ツールを作る人向けに、Oxcは部品をnpmパッケージとして公開しています。次の例では3つのパッケージを入れ、同じTSXファイルをパース・変換・型定義生成・圧縮します。

npm i -D oxc-parser oxc-transform oxc-minify

// src/app.tsx（入力）
import { useState } from "react";
interface Props { label: string; count?: number }
export function Counter({ label, count = 0 }: Props): JSX.Element {
  const [n, setN] = useState<number>(count);
  var unused = 1;
  if (n == null) { debugger; }
  return <button onClick={() => setN(n + 1)}>{label}: {n}</button>;
}
export const add = (a: number, b: number): number => a + b;

oxc-parserによるASTとエラー情報の取得

parseSync(ファイル名, ソース) は、ASTとエラーの配列を返します。言語はファイル名の拡張子から推定されるので、.tsx を渡せばTypeScriptとJSXの両方が解釈されます。公式によると、Test262のパーサーテストはすべて、BabelとTypeScriptのテストは99%を通過しています。ESMのimport／export情報も一緒に返すので、es-module-lexerを別に入れる必要はありません。

import { parseSync } from "oxc-parser";
import { readFileSync } from "node:fs";
const code = readFileSync("src/app.tsx", "utf8");
const p = parseSync("app.tsx", code);
console.log(p.errors.length, p.program.body.length, p.program.body[0].type);
// => 0 4 ImportDeclaration

oxc-transformによる型除去・型定義生成とランタイムヘルパー

transformSync はTypeScriptの型注釈を取り除き、JSXを関数呼び出しに変換します。isolatedDeclarationSync はTypeScriptコンパイラを使わずに型定義ファイルを出力します。前提は、TypeScriptの isolatedDeclarations の制約（公開する関数の戻り値型を明示するなど）を満たしたコードであることです。

import { transformSync, isolatedDeclarationSync } from "oxc-transform";
const t = transformSync("app.tsx", code, {
  typescript: {}, jsx: { runtime: "automatic" }, target: "es2020",
});
const d = isolatedDeclarationSync("app.tsx", code);

// t.code（抜粋）
import { jsxs as _jsxs } from "react/jsx-runtime";
export function Counter({ label, count = 0 }) {
	const [n, setN] = useState(count);
	...
	return /* @__PURE__ */ _jsxs("button", {
		onClick: () => setN(n + 1),
	...

// d.code（抜粋）
export declare function Counter({ label, count }: Props): JSX.Element;
export declare const add: (a: number, b: number) => number;
export {};

変換は型を外すだけで、var unused や debugger は残ります。型チェックもしないので、型エラーのあるコードもそのまま出力されます。型の検査は別に tsc で行います。

target を古い版に下げると、出力に @oxc-project/runtime からのimportが入ります。target: "es2015" で非同期関数とオブジェクトのスプレッドを含むコードを変換したところ、次の2行が先頭に付きました。es2017 では非同期関数がそのまま残り、スプレッド用の1行だけになります。

import _objectSpread from "@oxc-project/runtime/helpers/objectSpread2";
import _asyncToGenerator from "@oxc-project/runtime/helpers/asyncToGenerator";

トランスフォーマーのドキュメントによると、helpers.mode が "Runtime" のとき、ヘルパーを @oxc-project/runtime から読み込みます。Babelの @babel/runtime にあたるパッケージなので、変換後のコードを配布するなら依存に入れておきます。

oxc-minifyによる不要コード除去と圧縮

上の変換結果を minifySync("app.js", t.code, { mangle: true, compress: true }) に渡すと、未使用の変数と debugger が消え、変数名が1文字に短縮されました。

import{useState as e}from"react";import{jsxs as t}from"react/jsx-runtime";export function Counter({label:n,count:r=0}){let[i,a]=e(r);return t(`button`,{onClick:()=>a(i+1),children:[n,`: `,i]})}export const add=(e,t)=>e+t;

文字列リテラルがバッククォートに置き換わっているのは、エスケープが少なく済む引用符を選ぶ仕様によるものです。ミニファイアはコードの書き方に前提を置いて最適化しており、その一覧が crates/oxc_minifier/docs/ASSUMPTIONS.md にあります。getterの副作用やグローバルの書き換えに依存するコードでは、先に目を通してください。

OxlintとOxfmtをプロジェクトに入れる手順

どちらもRust製のバイナリがnpm経由で入り、Node.js側の依存はほとんど増えません。Oxlintのルール一覧やESLint・Biomeとの細かな比較はOxlintとESLintの違いとは？読み方・速度実測・移行手順とBiomeとの比較で扱っているので、ここでは導入に必要な要点だけを示します。

Oxlintの無設定実行と型情報付きルール

npm i -D oxlint
npx oxlint src
// src/app.tsx:5:7: warning eslint(no-unused-vars): Variable 'unused' is declared but never used. ...
// src/app.tsx:6:20: warning eslint(no-debugger): `debugger` statement is not allowed ...
// Finished in 67ms on 2 files with 96 rules using 16 threads.

設定ファイルが無くても、eslint・typescript・unicorn・oxcの4プラグインの既定ルールが警告として動きます。1.89.0では既定の111本のうち、型情報の要らない96本が実行されました（oxc はOxc独自のルール群です）。警告だけなら終了コードは0なので、CIで落とすなら --deny-warnings を付けるか、npx oxlint --init で correctness を "error" にした .oxlintrc.json を作ります。行単位の除外はESLintと同じ // oxlint-disable-next-line です。

型情報が必要なルールは、TypeScript 7（Go製のtsgo）を使う oxlint-tsgolint を足すと動きます。2026年7月22日に安定版となり、typescript-eslintの型情報ルール61個のうち59個に対応しています。Oxc傘下では、TypeScript 7のコンパイラをRustへ移植した型チェッカーtsrsも公開されています。導入手順と採用の判断はtsrsとは：Rust製TypeScript型チェッカーの使い方とCI導入の判断基準で解説しています。

async function save(): Promise<void> {}
export function run() {
  save();
}

npm i -D oxlint-tsgolint@7
npx oxlint --type-aware src/p.ts
// src/p.ts:3:3: warning typescript(no-floating-promises): Promises must be awaited, add void operator to ignore.

--type-aware を付けないと、このawait漏れは報告されません。

Oxfmtの導入とPrettierとの差：既定の行幅は100

npm i -D oxfmt
npx oxfmt --check .   # 差分があれば終了コード1
npx oxfmt             # 書き換え
npx oxfmt --migrate prettier   # .prettierrc から .oxfmtrc.json を生成

既定の printWidth は、Prettierの80に対してOxfmtは100です。90字の1行を整形すると、Oxfmt 0.74.0は1行のまま残し、Prettier 3.9.10は5行に折り返しました。--migrate prettier は .prettierrc の printWidth などを引き継ぎ、"sortPackageJson": false も書き足しました。Oxfmtは既定でpackage.jsonのキーを並べ替えるため、Prettierと結果を揃える設定です。

Prettierとの互換性の書き方は、2026年10月に変わりました。以前の「PrettierのJavaScript・TypeScript適合テストを100%通過」に代わり、現在の移行ガイドは「Prettierの出力を基準にし、Prettier側の不具合は意図的に変える」と説明し、その違いを「Known divergences」に理由つきで並べています。出力が最も近いのはPrettier 3.9.9です。Prettierプラグインは読み込めませんが、import・Tailwind CSSのクラス・package.jsonの並べ替えとJSDocの整形を組み込みで持っています（既定で有効なのはpackage.jsonだけ）。

言語サポートの一覧では、JavaScript・TypeScript・JSON・CSS系・GraphQL・TOML・YAML・Markdown（0.72から）をRustでネイティブに整形し、HTML・Vue・Svelte・Astro・MDXなどは同梱のPrettierが処理します。手元でも、Markdown内のTOMLコードブロックの b = [1,2] が b = [1, 2] に整形されました。

React・Vue・SvelteでのOxlintとOxfmtの対応範囲

Reactで使うときに最初につまずくのは、Reactのルールが既定で動かないことです。組み込みプラグインの一覧で既定が有効なのは eslint・typescript・unicorn・oxc の4つだけで、react・nextjs・jsx-a11y・vue・import などは自分で有効にします。

次のコンポーネントは、条件分岐の中で useState を呼び、map で作る要素に key がありません。

export function Box({ open }) {
  if (open) {
    const [v] = useState(0);
    return <div>{v}</div>;
  }
  return <ul>{[1, 2].map((i) => <li>{i}</li>)}</ul>;
}

npx oxlint r                     # 何も報告されない
npx oxlint --react-plugin r      # react(jsx-key) の1件だけ
npx oxlint --react-plugin -W react/rules-of-hooks r
// warning react-hooks(rules-of-hooks): React Hook "useState" is called conditionally. ...

プラグインを有効にしても、Hooksの呼び出し規則を見る rules-of-hooks は pedantic カテゴリに入っているため動きません。jsx-key と exhaustive-deps は correctness カテゴリなので、プラグインを有効にするだけで動きます。Reactのプロジェクトでは、.oxlintrc.json の rules で "react/rules-of-hooks": "error" を明示しておくのが確実です。設定ファイルで plugins を書くと既定の4つが外れるので、必要なものはすべて列挙します。

Vue・Svelteのファイルは、Oxlintでは <script> ブロックが検査対象です。Astroでは、これに加えて --- で囲まれたフロントマターも検査します。テンプレート部分の検査には対応していません。Oxfmtでは、.svelte は svelte パッケージの導入と svelte オプションの有効化、.astro は @astrojs/compiler-rs の導入と astro オプションの有効化が必要です。

VS Code拡張oxc.oxc-vscodeとエディタ連携

VS Codeでは、Marketplaceの公式拡張「Oxc」（ID：oxc.oxc-vscode）を入れます。拡張自体はツールを内蔵していません。プロジェクトにインストールした oxlint をリント用、oxfmt を整形用の言語サーバーとして起動する仕組みなので、先に npm i -D oxlint oxfmt（使う方だけでも可）が必要です。同じ拡張はOpen VSX Registryにも公開されており、CursorなどOpen VSXを使うエディタにも入ります。

チームで揃えるなら、.vscode/extensions.json で拡張を推奨に入れ、.vscode/settings.json で保存時の自動修正と既定のフォーマッターを設定します。

// .vscode/extensions.json
{ "recommendations": ["oxc.oxc-vscode"] }

// .vscode/settings.json
{
  "editor.codeActionsOnSave": { "source.fixAll.oxc": "always" },
  "oxc.typeAware": true,
  "editor.defaultFormatter": "oxc.oxc-vscode"
}

oxc.typeAware は型情報付きの検査をエディタ上でも有効にする設定で、使う場合は oxlint-tsgolint もインストールしておきます。この設定を書かなければ、.oxlintrc.json の options.typeAware の値が使われます。VS Code以外では、ZedとJetBrains（IntelliJ IDEA・WebStorm）に公式の拡張があり、Neovimはnvim-lspconfigの vim.lsp.enable('oxlint')、ほかのLSP対応エディタは oxlint --lsp の登録で使えます。

Claude Code・CodexなどのAIコーディングエージェントでOxlintを回す設定

Oxlintには、AIエージェントが読むことを想定した出力形式 --format=agent があります。CHANGELOGによると、1.63.0（2026年5月5日）で追加され、1.66.0（5月18日）からはエージェントの中で実行されたことを検知して自動で切り替わります。人が端末で実行するとコードの前後を枠で囲んだ形式ですが、Claude Codeの中で同じ npx oxlint src を実行すると、1件1行の形式になりました。

src/app.tsx:5:7: warning eslint(no-unused-vars): Variable 'unused' is declared but never used. ... help: Consider removing this declaration.
src/app.tsx:6:20: warning eslint(no-debugger): `debugger` statement is not allowed help: Remove the debugger statement

1.89.0で試すと、CLAUDECODE・AI_AGENT・CODEX_SANDBOX のどれか1つがあれば切り替わり、すべて外すと既定の形式に戻りました。配布バイナリには、Gemini CLI・GitHub Copilot CLI・Cursorのエージェント・Junie・OpenCode向けの環境変数名も入っています。人が読む形式に固定したいときは --format=default を明示します。

公式のCoding agentsのページは、エージェントに編集後の検査を任せる設定例を載せています。Codexでは、プロジェクト直下の AGENTS.md に「変更後に npx oxlint --fix と npx oxfmt を実行し、終える前に npx oxlint --deny-warnings --format=agent を通す」と書きます。--deny-warnings は警告が1件でも残れば終了コード1を返すので（手元でも上の2件で1）、警告が残ったことを終了コードで判定できます。ただし、AGENTS.mdは指示であり、エージェントの終了を機械的に止める仕組みではありません。Claude Codeでは、ファイルを編集した直後に動くフック（PostToolUse）を .claude/settings.json に書きます。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "file=$(jq -r '.tool_input.file_path'); npx oxlint --fix --no-error-on-unmatched-pattern \"$file\"; npx oxfmt --no-error-on-unmatched-pattern \"$file\""
          }
        ]
      }
    ]
  }
}

このフックは、編集されたファイル1つだけに安全な自動修正と整形をかけます。毎回プロジェクト全体を処理することはありません。実行には jq が必要です。

Vite 8とRolldownの中で動くOxc

Oxcを直接インストールしていなくても、Vite 8（2026年3月12日リリース、現行8.3.5）を使っていれば、Oxcはビルドの中で動いています。Vite 8は、開発時のesbuildと本番ビルドのRollupを、Rust製の単一バンドラーRolldown（1.0は2026年5月7日、現行1.2.15）に置き換えました。バンドルはRolldownの担当で、Rolldownが構文解析・変換・圧縮にOxcの部品を使います。RollupとRolldownの関係はRollupとツリーシェイキングの仕組み｜sideEffects・treeshake設定とnpm導入、Vite 8以降の位置づけで書きました。

Viteのビルド設定のドキュメントによると、Oxcのミニファイアはterserより30〜90倍速く、圧縮率はterserより0.5〜2%劣ります。Vite 7までの esbuild オプションに書いたJSXの設定は、互換レイヤーで読み替えられますが、oxc オプションへ移しておきます。

Reactでは、Vite 8と同時に出た @vitejs/plugin-react v6がReact Refreshの変換にOxcを使い、Babelへの依存がなくなりました。以前「Oxc版」として配布されていた @vitejs/plugin-react-oxc は2025年11月の0.4.3以降更新がなく、Vite 8では通常のplugin-reactを使えば足ります（@vitejs/plugin-react とは？v6（Vite 8・Babel廃止）の導入設定と plugin-react-swc との違い）。React Compilerは、2026年8月に公開されたOxc版の oxc-transform-react を使い、plugin-react 6.1.0から実験的な機能として動かせます。

OxlintとOxfmtも1つのコマンドで扱いたいなら、公式のOxfmtのページはOxlintとOxfmtを内蔵するVite+を案内しています。使い方はVite+とは？vpコマンドの使い方と1.0の中身・既存Vite案件の移行手順を実装目線で解説にまとめました。

SWC・Babelとの違いとパース速度の実測

OxcとSWCはどちらもRust製のBabel代替ですが、SWCはトランスパイルとミニファイが中心で、Next.jsなどに組み込まれて使われてきました（SWCとは？Rust製コンパイラの設定と採用判断を実装目線で解説）。Oxcはそこにリンターとフォーマッターを加え、ESLint・Prettierの置き換えまで同じAST上に揃えています。Biomeのパーサーは、ASTではなくCSTを作るので、パーサーの速度は同じ条件で比べられません。

手元で、TypeScript 5.9.3に同梱の typescript.js（9,112,572バイト）をNode.jsからパースし、戻り値のASTの program を読むところまでを測りました。各パーサーを1回事前に実行してから5回測った中央値を、3回の計測でさらに中央値にしています。AST取得までと全ノード走査までは、別々に測りました。環境はIntel Core i9-9880H・node v26.5.0です。ほかの処理も動いている状態で測っており、計測値は回ごとに最大約1.7倍ずれましたが、AST取得までの順位は3回とも同じでした。

既定設定のoxc-parserはASTをJSON文字列で渡し、program を初めて読んだ時点で JSON.parse します。parseSync の呼び出しだけなら326msで速く見えますが、ASTを読むとBabelより遅くなります。experimentalRawTransfer: true を付けると、Rust側のASTをバッファ経由で直接読むため203msまで縮みます。AST全体（Oxcで951,617ノード）を走査する処理まで含めると、既定設定とBabelはほぼ同じで回によって順位が入れ替わり、experimentalRawTransferだけが4倍以上速い結果でした。

import { parseSync, rawTransferSupported } from "oxc-parser";
import { readFileSync } from "node:fs";
// 事前に npm i -D [email protected] を実行
const code = readFileSync("node_modules/typescript/lib/typescript.js", "utf8");
console.log(rawTransferSupported()); // => true（64bit・Node.js 22以上など）
const { program } = parseSync("typescript.js", code, { experimentalRawTransfer: true });

パッケージのソースコメントによると、この方式が使えるのは64bitのリトルエンディアン環境で、Node.js 22以上またはDeno 2以上です。Bunは対象外です。名前のとおり実験的なオプションなので、使う前に rawTransferSupported() で確認してください。公式の「SWCの3倍」はRustのクレート同士の比較で、MacBook Pro M3 Maxのtypescript.jsでは、ASTの解放時間を含めないno-drop計測でOxc 26.3ms・SWC 84.1msです。Node.jsからでは、ASTを渡す方式の違いで順位が入れ替わるので、自分の入力で測り直してください。

Oxcへの全面移行を見送るべき場面

移行の判断では、速度だけでなくルールの互換性と整形の差分も確認します。次の条件に当てはまるプロジェクトでは、ESLint・Prettierとの併用から始めて差分を確かめる方が安全です。

• 社内製・マイナーなESLintプラグインに依存している：OxlintはESLint互換のJSプラグインを読み込めますが、公式ドキュメントはこの機能をまだアルファとしています。ルールの挙動差を確かめるまでは、該当ルールだけESLintに残してください。ESLint側の設定はESLintをVSCodeで使う設定手順｜ESLint 10のflat configと保存時の自動修正にまとめています。
• Prettierプラグインで独自の整形をしている：Oxfmtはプラグインを読み込めません。組み込みの並べ替えや同梱のPrettierで代替できない整形があるなら、Prettierを残します。
• Vueのテンプレートを検査している：Oxlintは .vue のscriptブロックしか見ないので、テンプレートのルールはeslint-plugin-vueに任せたままにします。
• パーサーやトランスフォーマーのAPIに直接依存するツールを作る：0.x系で、9月21日の0.151.0から10月19日の0.155.0まで、4週間でマイナー版が4回上がりました。npmのキャレット指定は0.x系ではパッチ版しか上げないので、^0.155.0 のままでは0.156.0が入りません。上げるたびにAPIの差分を確認して版を書き換える運用が前提です。
• 型エラーの検出をビルドに任せている：oxc-transformもVite 8も型チェックはしません。tsc --noEmit を別に回すか、実験的な機能である oxlint --type-aware --type-check を使います。

逆に、ESLintのCI時間が長いモノレポ、Prettierの標準設定のまま使っている新規プロジェクト、Vite 8へ移行済みのプロジェクトは、切り替えの効果が大きい候補です。その場合も、使っているESLintルールがOxlintにあるかと、Oxfmtで出る整形差分を切り替え前に確認してください。ビルド基盤やCIの作り直しを含む開発は、弊社のフルスクラッチ開発でも承っています。

よくある質問

Oxcの読み方は？

公式サイトの発音表記は /oʊ ɛks siː/ で、「オーエックスシー」と読みます。日本語圏では「オックス」と呼ばれることもあります。リンターのOxlintは「オーエックスリント」、フォーマッターのOxfmtは「オーエックスフォーマット」が公式の発音です。

OxcとOxlintは何が違いますか？

Oxcはプロジェクト全体の名前で、Oxlintはその中のリンターです。ESLintの代わりを探しているなら、Oxlintだけを入れれば足ります。

OxcはSWCやBabelの代わりになりますか？

TypeScriptの型除去、JSX変換、ES2015までの構文変換、ミニファイという用途なら代わりになります。Vite 8ではすでにOxcが既定です。一方、Babelのプラグインで独自の構文変換をしている場合は、そのまま置き換えられません。Oxcが対応しているのは、styled-componentsなど一部の組み込みプラグインだけです。

VS CodeでOxcを使うには？

プロジェクトに npm i -D oxlint で入れたうえで、公式拡張 oxc.oxc-vscode をインストールします。拡張はプロジェクト内のoxlintを起動するので、入っていないと動きません。保存時の自動修正は "source.fixAll.oxc": "always" で有効になります。

Oxcはバンドラーですか？

いいえ。Oxcにバンドラーは含まれていません。複数のファイルを束ねるのは、同じVoidZeroが開発するRolldownの役割です。RolldownがOxcのパーサー・トランスフォーマー・ミニファイア・リゾルバーを使っています。Viteのビルドの流れはVite + Reactの環境構築手順｜Viteとは・Vite 8.3の変更点とTypeScript 7対応で解説しています。

関連記事

• OxlintとESLintの違いとは？読み方・速度実測・移行手順とBiomeとの比較【1.88対応】
• SWCとは？Rust製コンパイラの設定と採用判断を実装目線で解説
• Biome v2とは？最新2.5系の導入・biome.json設定とESLint/Prettier移行
• Vite+とは？vpコマンドの使い方と1.0の中身・既存Vite案件の移行手順を実装目線で解説
• Vite + Reactの環境構築手順｜Viteとは・Vite 8.3の変更点とTypeScript 7対応