הגירה ל-TypeScript ב-FastComments הושלמה

! המאמר הזה מכיל סגנון טכני

מה חדש

ב-FastComments אנו מעריכים שפות עם טיפוסים סטטיים. במדויק יותר, אני אוהב מערכות טיפוס טובות עם קומפיילרים מהירים. FastComments התחילה עם האחרון - או בלי קומפיילר. בעוד שהיו לנו שתי שירותים שנכתבו ב-Java מודרנית במהלך השנה הראשונה, הספריות העיקריות של הבקאנד והפרונטאנד נכתבו ב-CJS JS שרץ על Node.

בהכנה לעשור הבא של פיתוח, העברנו את הרכיבים הגדולים ביותר של FastComments ל-TypeScript.

זה כלל העברת מעל 130,000 שורות קוד (100,000 מתוכן הן בבקאנד) על פני 1441 קבצים, ותיקון של מעל 8000 שגיאות קומפילציה.

וואו

זה נעשה תוך שבועיים.

הקפאת קוד - תודה

אני רוצה להודות ללקוחות שלנו על סבלנותם בהתמודדות עם כל עיכוב בעדכוני באגים או שחרור תכונות, שכן עשינו הקפאת קוד של שבועיים כדי להשלים את השדרוג הזה. תודה!

באגים שתוקנו

כפי שאתם יכולים לדמיין, תיקנו מספר באגים. רובם נגעו לגילוי ספאם ולאחסון.

שינויים משמעותיים

• כל נקודות הקצה של ה-API עכשיו מחזירות status: 'failed' במקום תמהיל של "failed" ו-"failure" כנ valores status. "success" נשאר ללא שינוי.
• לא נברר יותר את תצורת הווידג'ט הראשונה אם אין התאמה, במקום זאת, נחזיר את תצורת המערכת המוגדרת כברירת מחדל.

איך זה היה?

מצאנו, כמו בדרך כלל, שהרבה מהכלים באקו-סיסטם של NPM שיכולים לעזור עם המשימה הזו לא עבדו מאוד טוב. אז, השתמשנו ב-LLMs כדי לייצר סקריפטים לעשות חלק מהעבודה. למשל, השתמשנו במידה רבה ב-JSDoc, כך שהיינו יכולים לכתוב סקריפטים לקחת את ה-JSDoc ולמ_convert אותם לממשקי TypeScript והגדרות טיפוס, ולתייג כראוי את פרמטרי הפונקציה ואת סוגי החזר. השתמשנו גם בסקריפטים האלה כדי להעביר מ-CJS ל-ESM, שכללו כתיבה מחדש של ייבוא, ייצוא, וגילוי בעיות ריצה נפוצות כמו __dirname.

האם הזכרתי בעיות ריצה?

איך ה-TypeScript ב-2025?

TypeScript היא שפה נחמדה לכתיבת לוגיקה עסקית. אבל, ל-Java עדיין יש DevEx טוב יותר. אם Java, Go, או Rust מקמפלים, ככל הנראה זה יעבוד. עם TypeScript, אני יכול לעשות משהו כמו:

console.log(__dirname);

... וזה יתממשק.

אבל זה לא ירוץ, עם מודולים מודרניים. ה-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: בדיקות יחידה בבקאנד עוברות
• יום 12: מתחילים להעביר את הפרונטאנד, 3118 שגיאות.
• יום 13: נמצאו 2172 שגיאות.
• יום 14: נמצאו 1224 שגיאות.
• יום 15: נמצאו 498 שגיאות.
• יום 16: כל שגיאות הקומפילציה תוקנו.
• יום 17: שוחרר. בדיקות E2E עוברות. 30 דקות של השבתה במהלך בעיות ריצה בלתי צפויות. :)

העתיד

עשינו את זה כדי לתמוך בפיתוח לעשור הבא. המערכת עכשיו מספיק גדולה כך שמהר יותר לפתח עם מערכת טיפוסים מאשר בלי אחת.

אתם יכולים גם לצפות שהספריה שלנו ל-TypeScript ב-NPM תשתפר, כפי שכבר התחילה, שכן אנחנו עכשיו משתמשים בעצמנו בספריה הזו בקוד השרת והלקוח שלנו.

נשחרר גם בקרוב SDKs לקוחות שנוצרו ישירות מקוד השרת, שזה היה מניע עיקרי סביב מאמץ זה.

לסיכום

כמו כל שחרור משמעותי, אנחנו שמחים שיכולנו לקחת את הזמן כדי לאופטם, לבדוק ולשחרר את השינויים האלה כראוי. הודיעו לנו מטה אם אתם מגלים בעיות כלשהן.

לחיים!