Fri Jan 31 2025

...

Завършена миграция на FastComments TypeScript

! Тази статия съдържа технически термини

Какво ново

В FastComments ценим статично типизираните езици. По-специално, харесвам солидни типови системи с бързи компилатори. FastComments започнахме с последното - или без компилатор. Докато имахме две услуги написани в модерен Java през първата година, основните библиотеки за бекенд и фронтенд бяха написани на CJS JS, работещи на Node.

В подготовка за следващото десетилетие на развитие, мигрирахме най-големите компоненти на FastComments към TypeScript.

Това включва мигриране на над 130k реда код (100k от тях е бекенд) в 1441 файла и поправяне на над 8000 компилационни грешки.

уууууу

Това беше направено за две седмици.

Замразяване на кода - Благодаря

Бих искал да благодаря на нашите клиенти за търпението им при закъсненията в поправките на бъгове или пускането на нови функции, докато извършвахме две седмици замразяване на кода за завършване на това обновление. Благодаря!

Поправени бъгове

Както можете да си представите, поправихме няколко бъга. Те бяха основно свързани с откриването на спам и кеширане.

Промени, които нарушават съвместимостта

• Всички API крайни точки сега връщат status: 'failed', вместо смес от "failed" и "failure" като стойности на статуса. "success" остава непроменен.
• Вече няма да се прилага по подразбиране конфигурацията на първия компонент, ако няма съвпадение, вместо това ще върнем стандартната системна конфигурация.

Какви бяха условията?

Установихме, че, както обикновено, много от инструментите в NPM екосистемата, предназначени да помогнат с тази задача, не работеха много добре. Затова използвахме LLMs за генериране на скриптове, за да свършим голяма част от работата. Например, ползвахме JSDoc в голяма степен, така че можем да пишем скриптове за взимане на JSDoc и преобразуването им в интерфейси на typescript и типови дефиниции, и правилно анотиране на аргументи на функции и типове на връщане. Също така използвахме тези скриптове за миграция от CJS към ESM, което включваше презаписване на импорти, експорти и откриване на общи проблеми при изпълнение като __dirname.

Споменах ли проблемите при изпълнение?

Какво е TypeScript през 2025?

TypeScript е приятен език за писане на бизнес логика. Но Java все пак предлага по-добро DevEx. Ако Java, Go или Rust компилират, най-вероятно ще работят. С TypeScript, мога да направя нещо подобно:

console.log(__dirname);

... и това ще компилира.

Но няма да се изпълни с модерни es модули. Вашият IDE дори ще завърши автоматично __dirname, а след това ще се провали при изпълнение. Изглежда като Spring DI, но по-зле.

Можете също така да правите неща като:

context.someImportantMethodToCall;

Сега, това е "изречение". То е валидно "изречение". На пръв поглед може да си помислите, че извикваме someImportantMethodToCall, но не го правим! Моят IDE, поне, не упреждава за това, нито пък компилаторът. Кодът просто няма да направи нищо (освен если someImportantMethodToCall е клас getter, в който случай автоматично се извиква...)

Решението е:

context.someImportantMethodToCall();

Мисля, че вероятно можете да откриете това с нещо като eslint и някакво правило "без странични ефекти", но тогава ще въвведете друг голям комплект библиотеки за поддържане, и след това eslint трябва да анализира цялата ви кодова база при всяко изграждане, инструментите са бавни и така нататък - не, благодаря. Въздействието върху производителността при работа с бавни инструменти като eslint е било по-съществено в кариерата ми в предишни работи, отколкото "увеличението" на производителността, което някога съм получил от малките неща, които eslint поправя/предотвратява с разстояния и т.н. Има по-бързи алтернативи, които излизат сега, което е страхотно.

TypeScript е наистина приятен заради езиковите функции като Pick<User, 'username', 'email'>. Това, в комбинация с извод на типове, предоставя начин за безопасни за тип резултати от заявките от базата данни за подмножества от по-големи обекти без да е необходимо да дефинирате клас за всяка форма. Pick е нещо, от което съм изненадан, че Scala няма. Типови Обединения също са много приятни.

Инкременталните изграждания също работят разумно добре, само увеличихме времето за изграждане в CI с около 5 - 10 секунди средно, за изграждане на споделената библиотека, фронтенда и бекенда.

Хронология на развитието

За тези, които са любопитни, ето как изглеждаше нашето напредване:

• Ден Първи: Намиране на 5564 грешки в 362 файла.
• Ден Втори: Намиране на 4034 грешки в 239 файла.
• Ден Трети: Намиране на 3784 грешки в 191 файла.
• Ден Четвърти: Намиране на 2974 грешки в 169 файла.
• Ден Пети: Намиране на 3000 грешки в 171 файла.
• Ден Шести: Намиране на 2916 грешки в 165 файла.
• Ден Седми: Намиране на 2618 грешки в 157 файла.
• Ден Осми: Намиране на 2253 грешки в 109 файла.
• Ден Девети: Намиране на 1605 грешки в 69 файла.
• Ден Десети: Намиране на 686 грешки в 53 файла.
• Ден 11: Бекенд Unit тестове преминали успешно
• Ден 12: Започваме миграцията на фронтенда, 3118 грешки.
• Ден 13: Намиране на 2172 грешки.
• Ден 14: Намиране на 1224 грешки.
• Ден 15: Намиране на 498 грешки.
• Ден 16: Всички компилационни грешки поправени.
• Ден 17: Издадено. E2E тестовете преминават успешно. 30 минути прекъсване по време на неочаквани проблеми при изпълнение. :)

Бъдещето

Направихме това, за да подкрепим развитието за следващото десетилетие. Системата е сега достатъчно голяма, че е по-бързо да се развива с типова система, отколкото без такава.

Можете също така да очаквате нашата TypeScript библиотека на NPM да се подобрява, тъй като вече е започнала, след като в момента я използваме активно в нашия сървърен и клиентски код.

Скоро ще публикуваме и генерирани клиентски SDK директно от сървърният код, което беше основна мотивация за това усилие.

В заключение

Както при всички основни версии, ни е приятно, че можехме да отделим време да оптимизираме, тестваме и правилно да пуснем тези промени. Уведомете ни по-долу, ако откриете някакви проблеми.

Наздраве!