Компилятор файла: Babel, SWC, Oxc — и нужен ли вам Babel

Сборщик из прошлой статьи работал с графом: какие файлы нужны, в каком порядке их выполнять, что увезти в отдельный кусок и как назвать файл. Внутрь файла он не заглядывал — для него это была строка. А внутри файла своя работа. JSX и аннотации типов браузер не разберёт. Константы режима сборки нужно подставить. И чтобы найти импорты, текст нужно разобрать, не путая код с комментарием и строкой. Эту работу делает компилятор файла: получает текст одного файла и возвращает JavaScript, понятный браузеру.

В настоящей сборке слои — разные инструменты. А третий слой, проверка типов, стоит отдельно от обоих:

esbuild стоит в двух строках: он умеет и перевести файл, и собрать из файлов бандл — им в конце прошлой статьи резались куски. tsc тоже в двух: функция transpileModule из пакета шестой версии — той, что стоит в песочнице, — переводит ровно один файл, а команда tsc строит всю программу и проверяет её.

Проверка отделена не случайно. Чтобы сказать, что total(prices) вернёт строку, нужно открыть cart, из него — money, и так до конца цепочки: без всей программы тип не узнать. Компилятору файла соседи не нужны, ему хватает текста перед глазами. Поэтому файлы можно переводить независимо друг от друга, хоть параллельно, а проверку типов запускают отдельной командой. У этой независимости есть цена — правила вроде isolatedModules: файл обязан переводиться без соседей, потому что однофайловый компилятор в соседей не заглянет.

Такие компиляторы ещё называют транспайлерами: они переводят с языка на близкий язык, а не в машинный код. В документации инструментов встречаются оба слова.

Кроме перевода, компилятор файла подставляет константы сборки. Главная из них — process.env.NODE_ENV. В браузере объекта process нет, а библиотеки на эту строку опираются: пакет react по ней выбирает, какой файл отдать, отладочный или боевой. Поэтому сборка заменяет обращение строкой режима: "production" в выпускной сборке, "development" при разработке.

Проще всего заменить текст регуляркой — так в прошлой статье искали импорты. В файле ниже process.env.NODE_ENV встречается трижды: дважды в коде и один раз в тексте подсказки. new Function только разбирает получившийся код, не выполняя его. Прогноз: что станет со второй строкой и разберётся ли файл?

// подстановка «найти и заменить»: так проще всего вшить режим сборки
const source = [
  "const mode = process.env.NODE_ENV;",
  'const hint = "задайте process.env.NODE_ENV";',
  'if (process.env.NODE_ENV !== "production") {',
  '  console.log("отладка");',
  "}",
].join("\n");

const byRegex = source.replace(/process\.env\.NODE_ENV/g, '"production"');
console.log(byRegex.split("\n")[1]);

try {
  new Function(byRegex); // только разбирает код, не выполняя его
  console.log("код разбирается");
} catch (error) {
  console.log((error as Error).name);
}

Вторая строка сломана: "задайте "production"". Кавычки подстановки закрыли строку раньше времени, за ними осталось голое слово production, и разобрать такой файл нельзя — отсюда SyntaxError. Регулярка не отличает обращение к свойству от тех же букв внутри строки или комментария. Будь подсказка в одинарных кавычках, вышло бы хуже: файл разобрался бы, а текст подсказки молча поменялся.

Компилятор не ищет в тексте буквы. Сначала он разбирает файл в дерево: каждая конструкция кода становится узлом, у узла есть вид и место в тексте. В статье про линтер это было одной фразой — парсер превращает TypeScript в дерево. Здесь дерево окажется у вас в руках.

ts.createSourceFile разбирает исходник из прошлого примера. visit спускается по дереву через ts.forEachChild и ищет узел вида PropertyAccessExpression — обращение к свойству через точку — с текстом process.env.NODE_ENV. Найдя такой, запоминает, где он начинается и кончается, и внутрь не идёт: там лежат process.env и process, их заменять не нужно. Сами замены делаются в конце, по запомненным позициям, с последней к первой. Прогноз: сколько замен найдёт обходчик?

// ts — настоящий компилятор TypeScript: песочница загрузила его ради ваших примеров
declare const ts: any;
declare const source: string;

const tree = ts.createSourceFile("app.js", source, ts.ScriptTarget.Latest, true);
const edits: { start: number; end: number; text: string }[] = [];

function visit(node: any): void {
  if (ts.isPropertyAccessExpression(node) && node.getText() === "process.env.NODE_ENV") {
    edits.push({ start: node.getStart(), end: node.end, text: '"production"' });
    return;
  }
  ts.forEachChild(node, visit);
}
visit(tree);

let out = source;
for (const edit of edits.reverse()) out = out.slice(0, edit.start) + edit.text + out.slice(edit.end);
console.log("замен:", edits.length);
console.log(out);

ts здесь — настоящий компилятор TypeScript, который песочница загрузила ради ваших примеров. От него мы берём только разборщик и готовое дерево, а посетителя и правку пишем сами.

Замен две, подсказка цела. Для дерева текст в кавычках — узел StringLiteral: у него есть значение, но это не обращение к свойству, и условию посетителя он не подходит. Порядок «с конца» тоже не прихоть. "production" на восемь знаков короче process.env.NODE_ENV, и первая по тексту замена сдвинула бы позиции всех узлов за ней.

Разобрать, обойти, заменить узел — так устроен любой плагин компилятора. Вот тот же обходчик плагином Babel. Посетитель здесь — объект, где ключ — вид узла: Babel сам обходит дерево и зовёт метод MemberExpression на каждом обращении к свойству. matchesPattern сравнивает цепочку имён, replaceWith ставит на место узла новый строковый литерал. Позиции считать уже не нужно: Babel правит само дерево и печатает текст заново.

$ cat inline-node-env.mjs

Узел здесь называется MemberExpression, а у TypeScript — PropertyAccessExpression: у каждого компилятора свои имена узлов, а идея одна. Вторая половина плагина, IfStatement, — тема следующего раздела.

После подстановки в файле осталось условие if ("production" !== "production"). Это сравнение двух литералов: ответ известен на сборке, и проверять его в браузере незачем. Второй проход, свёртка, вычисляет такие условия и оставляет от if только ту ветку, которая выполнится. В подложке — результат прошлого примера. Прогноз: что останется от файла?

declare const ts: any;
declare const inlined: string;

const tree = ts.createSourceFile("app.js", inlined, ts.ScriptTarget.Latest, true);
let out = inlined;

function visit(node: any): void {
  const test = ts.isIfStatement(node) ? node.expression : null;
  if (test && ts.isBinaryExpression(test) && ts.isStringLiteral(test.left) && ts.isStringLiteral(test.right)) {
    const same = test.left.text === test.right.text;
    const passes = test.operatorToken.kind === ts.SyntaxKind.EqualsEqualsEqualsToken ? same : !same;
    const kept = passes ? node.thenStatement.getText() : (node.elseStatement?.getText() ?? "");
    out = out.slice(0, node.getStart()) + kept + out.slice(node.end);
    return;
  }
  ts.forEachChild(node, visit);
}
visit(tree);
console.log(out.trim());

Две строки. Условие ложно, ветки else нет — от if не осталось ничего, вместе с console.log("отладка"). Будь условие истинным, на месте if встал бы его блок. Так из выпускного бандла пропадает всё, что обёрнуто в сравнение с режимом: отладочные проверки, предупреждения, логи.

На том же держится выбор сборки React. Файл index.js пакета react — один if по режиму, а выпускная сборка Vite оставляет от него одну строку:

$ cat node_modules/react/index.js

Условие стало "production" === "production", свёртка оставила первую ветку, и react.development.js в бандл не попал вовсе. Заметьте, что исчез require, стоявший внутри ветки. Импорт в начале файла свёртка не тронула бы: она убирает ветки, а не импорты.

Теперь один и тот же файл через пять настоящих компиляторов. В input.tsx — те же три строки с режимом, тип и компонент с JSX. Babel работает с нашим плагином, SWC — с оптимизатором simplify и подстановкой globals.envs, Oxc и esbuild — с настройкой define (esbuild ещё и с minifySyntax), а tsc получает тот же файл через transpileModule. Прогноз: в чьём выводе останется ветка «отладка»?

$ cat input.tsx
export const mode = process.env.NODE_ENV;
export const hint = "задайте process.env.NODE_ENV";
if (process.env.NODE_ENV !== "production") {
  console.log("отладка");
}
type Props = { title: string };
export const Title = ({ title }: Props) => <h1 className="title">{title}</h1>;
$ node compare.mjs

Ветка осталась только у tsc. Четыре других вывода совпали по сути: mode = "production", подсказка цела, if исчез. Форма у всех своя — esbuild, например, склеил объявления в одно и собрал экспорты в конец, — а результат один. tsc стёр тип и переписал JSX, но process.env оставил: такой настройки у него нет, и подстановка — не его работа. Подстановку делает не «компилятор вообще», а тот, кому её настроили. В Vite и Next это делает сама сборка, в своём скрипте на esbuild — ваш define.

$ cat compare.mjs

Та же подстановка работает и в самом учебнике. React для песочницы собирает esbuild-ом скрипт сайта, и режим там задан явно:

// apps/web/scripts/build-ts-runtime.mjs — сборка React для песочницы учебника (фрагмент)
await build({
  stdin: {
    contents: `
      import * as React from 'react';
      import * as ReactDOM from 'react-dom/client';
      window.React = React;
      window.ReactDOM = ReactDOM;
    `,
    …
  },
  outfile: join(КУДА, 'react.js'),
  bundle: true,
  minify: true,
  format: 'iife',
  platform: 'browser',
  define: { 'process.env.NODE_ENV': '"development"' },
  logLevel: 'error',
});

Поэтому в песочнице стоит отладочная сборка React: условие из index.js свернулось во вторую ветку. Минификация включена, но тексты предупреждений и ошибок React остаются полными — ради них сборка и сделана отладочной: в примерах части IV вы то и дело предсказываете, что именно скажет React.

В Expo те же два прохода делают разные инструменты: в выпускной сборке babel-preset-expo подставляет вместо Platform.OS строку платформы, а ветку сворачивает constantFoldingPlugin из Metro, который прогоняет transform-worker из @expo/metro-config. Это разобрано на настоящем выводе в части про React Native. А на доске задач тем же приёмом в бандл вшиваются переменные NEXT_PUBLIC_.

Кроме констант, компилятор убирает из файла всё, чего нет в JavaScript. Первое — JSX. Что разметка становится вызовом функции, вы видели в статье про JSX. Какой именно функции — решает настройка компилятора. transpileModule переводит один и тот же файл дважды: с JsxEmit.React и с JsxEmit.ReactJSX. Прогноз: вывод займёт три строки — какие?

declare const ts: any;

// один и тот же файл, одна настройка jsx — две разные формы вызова
const tsx = 'export const el = <h1 className="title">Hi</h1>;';
for (const jsx of [ts.JsxEmit.React, ts.JsxEmit.ReactJSX]) {
  const result = ts.transpileModule(tsx, {
    fileName: "el.tsx",
    compilerOptions: { jsx, module: ts.ModuleKind.ESNext, target: ts.ScriptTarget.ES2023 },
  });
  console.log(result.outputText.trim());
}

JsxEmit.React — классический трансформ: разметка становится вызовом React.createElement, и React должен быть виден в файле. ReactJSX — автоматический: компилятор сам дописал импорт _jsx из react/jsx-runtime — это и есть третья строка, — а текст Hi переехал в пропсы как children. В песочнице учебника включён классический трансформ: разметка в примерах становится React.createElement, и эту функцию можно звать руками рядом с JSX. В проектах на Next.js, Vite и Expo включён автоматический. Его же настроили всем пяти компиляторам в сравнении выше, и импорт из react/jsx-runtime дописали все — только esbuild назвал функцию просто jsx.

При разработке функция ещё и другая. Вот начало main.tsx из шаблона react-ts в том виде, в каком Vite отдаёт его браузеру:

$ npx vite --port 3600
$ curl http://127.0.0.1:3600/src/main.tsx

Вместо _jsx — _jsxDEV из react/jsx-dev-runtime, и у каждого вызова лишние аргументы: имя файла, строка и колонка разметки в исходнике. Остальное в этом ответе — работа самого Vite, а не компилятора: голые имена пакетов переписаны на адреса в /node_modules/.vite/deps/, а в конце файла встроена карта кода.

Второе, что компилятор убирает, — типы. Прогноз: что останется от аннотации и сколько ошибок насчитает transpileModule, если записать строку в число?

declare const ts: any;

// компилятор файла видит один файл — и типы только стирает
const result = ts.transpileModule('export let count: number = "два";', {
  reportDiagnostics: true,
  compilerOptions: { module: ts.ModuleKind.ESNext, target: ts.ScriptTarget.ES2023 },
});
console.log(result.outputText.trim());
console.log("диагностик:", result.diagnostics.length);

Аннотация стёрлась, "два" осталось, диагностик ноль. transpileModule видит один файл и сообщает только об ошибках разбора: чтобы заметить, что строка не число, нужна вся программа. Oxc, SWC, esbuild и Babel поступают с типами так же. Поэтому в проекте, где файлы переводит не tsc, проверка типов живёт отдельной командой tsc --noEmit. Песочница учебника разведена так же: диагностики под примером даёт программа TypeScript, построенная рядом, а выполняется результат transpileModule — поэтому ошибка типов запуск не отменяет.

Раз у компилятора есть дерево, импорты из него достаются без регулярки. Это первая задача статьи.

В таблице первого раздела Babel стоит рядом с SWC и Oxc. Какой из них работает в вашем проекте, решает платформа, и ответ меняется от версии к версии. Поэтому таблица — с датой, на 14.09.2026:

Последняя строка — про сам Babel. Восьмая версия, по словам команды, новых функций не принесла. Заметнее всего для старого проекта, что @babel/preset-env по умолчанию больше не понижает код до ES5 — только если попросить явными targets. А седьмая ветка, на которой работает Metro, пока получает исправления безопасности.

Для веба из таблицы следует простое: настраивать Babel в Next и Vite не нужно, а завести его можно случайно. Хватит .babelrc, оставшегося от старого проекта. Ниже его положили в приложение из прошлой статьи. Прогноз: промолчит ли next build, найдя такой файл?

$ echo '{ "presets": ["next/babel"] }' > .babelrc
$ npx next build

Не промолчит. Turbopack включил Babel для файлов проекта и написал об этом строкой Using external babel configuration, а раз в конфиге только стандартный пресет next/babel, предупредил, что файл, похоже, лишний. SWC при этом никуда не делся: внутренние преобразования Next и понижение синтаксиса делает он. В режиме --webpack жёстче: Disabled SWC as replacement for Babel — файлы проекта переводит Babel вместо SWC, а опции compiler из конфига Next больше не действуют. Если такие строки появились в вашем логе, а в babel-конфиге нет ничего, кроме next/babel, — конфиг можно удалять, о том и предупреждение.

Главное исключение в вебе — React Compiler. Он выпущен плагином Babel, и флаг reactCompiler в Next без пакета babel-plugin-react-compiler не соберётся. Но у обеих платформ уже есть экспериментальный порт компилятора на Rust, которому Babel не нужен. В Next это флаг experimental.turbopackRustReactCompiler — как его включить и что он выпускает, покажет статья про Turbopack. В Vite — react({ compiler: true }) вместе с пакетом oxc-transform-react.

$ npm i -D oxc-transform-react@0.145.0
$ cat vite.config.ts
import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react({ compiler: true })],
})
$ mv node_modules/@babel node_modules/@babel.off && mv node_modules/babel-plugin-react-compiler node_modules/babel-plugin-react-compiler.off
$ npx vite build --minify false --outDir dist-rust

Итог для веба: Babel нужно узнать в лицо и не завести случайно. Его след в проекте — babel-конфиг в корне и строка Using external babel configuration в логе сборки. В Expo и React Native всё наоборот: Babel — рабочая часть сборки. Через него не только подставляется платформа, но и работают плагины библиотек — например, плагин react-native-worklets, который находит в компоненте функции для UI-рантайма Reanimated. А какой сборщик приходит с какой платформой и когда выбирать его самому, разбирает последняя статья главы.