Обзор

В gt-next 6.2.0 мы сделали большой шаг к переносу обработки с этапа выполнения на этап сборки с помощью плагина SWC. Такой подход открывает новые возможности, такие как хеширование на этапе компиляции, предварительный рендеринг переводов и более строгая проверка — и всё это без дополнительной нагрузки в рантайме.

Чтобы не распыляться, мы начали с трёх ключевых улучшений.

• Хеширование на этапе компиляции
• Перевод по запросу
• Правила линтинга на этапе сборки

Хеширование на этапе компиляции

Хотя это относительно небольшая оптимизация, теперь мы выполняем вычисление хешей на этапе сборки, а не во время выполнения.
Функциям вроде getGT() и серверному <T> больше не нужно вычислять и кэшировать хеши при каждом вызове, что обеспечивает более стабильную производительность.

Перевод по запросу

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

getGT() и useGT() следуют знакомому паттерну i18n:

export default function Page() {
  const t = useGT()
  // const t = await getGT(); для серверной части

  return (
    <>
      {t('контент для перевода')}
      {t('другой контент для перевода')}
    </>
  )
}

Мы намеренно оставили t() синхронной, чтобы соответствовать другим i18n‑библиотекам. Обратной стороной был «двухэтапный процесс перевода»:

1. Зарегистрировать текст через API. 2. Дождаться второго рендера, чтобы отобразить переведённый результат.

Теперь, благодаря компилятору, переводимый контент заранее сканируется и передаётся напрямую в useGT() или getGT() на этапе компиляции. Это означает, что переводы сразу доступны во время выполнения — без перезагрузки страницы.

Линтинг на этапе сборки

Раньше, чтобы обнаружить некорректное использование компонентов <T>, нужно было запускать gtx-cli с кастомным линтером. Это приводило к несоответствиям между поведением в разработке и продакшене.

Начиная с версии 6.2.0, правила линтинга теперь применяются напрямую в SWC‑плагине. Если какой-либо переводимый контент не обёрнут в компонент <T>, вы получите ошибку на этапе сборки, что позволяет выявлять проблемы на ранней стадии.

Почему SWC (пока)?

Наш переход от выполнения логики в рантайме к выполнению на этапе сборки все еще на ранней стадии. Мы начинаем с Next.js, но вскоре планируем поддерживать и другие фреймворки. Плагины Babel с аналогичной функциональностью уже в дорожной карте.

gt-next 6.2.0 закладывает основу для более быстрого и надежного процесса локализации. Перенося логику на этап сборки, мы снижаем сложность рантайма и делаем переводы более оперативными и предсказуемыми.