Що сталося

Для перевірки типів команда випробувала TSGO — нову реалізацію інфраструктури TypeScript мовою Go. За даними автора, повна початкова перевірка скоротилася з 66,4 до 6,39 секунди, а середнє використання пам’яті — приблизно з 447 до 76 МБ. Проєкт іще активно розвивається, отже перед впровадженням його варто перевірити на власному репозиторії та в безперервній інтеграції.

Схожий шлях пройшов аналіз коду: від ESLint через Biome до Oxlint. Biome був швидким у наведених вимірах, але в описаному випадку бракувало частини правил, а процес у редакторі інколи аварійно завершувався. Oxlint, написаний на Rust, не очолив кожен порівняльний тест, зате зберіг потрібне покриття правил і стабільно працював щодня.

Найпомітніша зміна стосувалася збирання. Після Webpack і перевірки Vite, який не відповів потребам цієї схеми мікрофронтендів із Module Federation, команда обрала Rsbuild на основі Rspack. Автор повідомляє про скорочення гарячого оновлення приблизно з 36 секунд до однієї та про менший підсумковий пакет. Вирішальною була не лише швидкість, а й сумісність.

Чому це важливо

Кілька секунд в одній операції здаються дрібницею, доки вони не повторюються для всієї команди. У матеріалі наведено простий розрахунок: 40 розробників, які роблять по 50 циклів «змінив — перевірив» на день, можуть виграти майже 20 годин на добу, якщо скоротити очікування з 36 секунд до однієї. Це оцінка автора, але вона добре показує накопичувальну ціну повільного зворотного зв’язку.

Важлива й послідовність рішень. Швидше збирання мало допомагає, якщо аналіз коду або перевірка типів і далі затримують зміни в безперервній інтеграції. Водночас заміна зрілого інструмента заради гарного порівняльного тесту може коштувати дорожче за виграш, якщо зламаються плагіни, правила або поведінка мікрофронтендів.

Окремий шар проблеми — розсинхронізація клієнтської та серверної частин. Автор пропонує вважати swagger.json єдиним контрактом і автоматично отримувати з нього типи та функції для API. Тоді змінений контракт стане помилкою збирання до об’єднання змін, а не несподіванкою під час роботи застосунку.

На практиці

Починати варто з вимірювань у реальному репозиторії, а не з чужої таблиці. Окремо виміряйте повну й повторну перевірку типів, аналіз коду, час гарячого оновлення, використання пам’яті та тривалість перевірок у безперервній інтеграції.

Після цього зміни можна впроваджувати невеликими кроками:

1. Запустіть TSGO як окрему перевірку безперервної інтеграції та порівняйте його висновки з поточним tsc.
2. Перевірте Oxlint або інший аналізатор на наявному наборі правил: пропущені перевірки важливіші за швидший запуск.
3. Зробіть пробний перехід на Rsbuild для однієї частини застосунку, особливо за наявності Module Federation, нестандартних завантажувачів чи плагінів Webpack.
4. Генеруйте клієнт API з опублікованого контракту й зберігайте оновлені типи разом зі зміною серверного API.
5. Увімкніть React Compiler поступово, стежачи за поведінкою компонентів і порівнюючи продуктивність до та після переходу.

React Compiler завершує цю картину, переносячи частину ручної мемоізації на етап компіляції. Він може зменшити кількість захисних обгорток useMemo, useCallback і memo, але сам по собі не виправить важкі обчислення, невдалі межі стану чи слабку архітектуру компонентів.

Підсумок

Головна думка матеріалу не в обов’язковому наборі з п’яти назв, а в дисципліні роботи із затримками. Команда отримує перевагу, коли розробник швидше бачить наслідок зміни, а несумісність контрактів і правил виявляється до випуску.

TSGO, Oxlint, Rsbuild і React Compiler варто оцінювати як частини єдиної системи зворотного зв’язку, а не як модні заміни. Для малого застосунку частина переходів не окупиться; для великої кодової бази навіть кілька секунд у частих операціях можуть відчутно змінити робочий день.