העברת ה-Puppeteer ל-TypeScript

Jack Franklin

אנחנו בצוות DevTools אוהבים מאוד את TypeScript – עד כדי כך שאנחנו כותבים קוד חדש ב-DevTools באמצעות TypeScript, ואנחנו באמצע תהליך העברה גדול של כל קוד הבסיס כדי לבצע בדיקת סוגים באמצעות TypeScript. מידע נוסף על ההעברה הזו זמין בשיחה שלנו ב-Chrome Dev Summit 2020. לכן, היה הגיוני לבדוק גם העברה של קוד הבסיס של Puppeteer ל-TypeScript.

תכנון ההעברה

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

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

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

דבר אחד שבו השקענו זמן מראש היה הגדרת האינטגרציה הרצייפה (CI). שמנו לב שהפעלת CI נגד בקשות משיכה הייתה לא יציבה ולרוב נכשלה. זה קרה כל כך הרבה פעמים עד שהתרגלנו להתעלם מ-CI ולמזג את בקשות המשיכה בכל מקרה, מתוך הנחה שהכשל היה בעיה חד-פעמית ב-CI ולא בעיה ב-Puppeteer.

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

בחירת קובץ אחד והעברתו ל-AWS

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

בנוסף, העובדה שבדקנו קובץ אחר קובץ (ופרסמנו גרסאות רגילות של Puppeteer, כך שכל השינויים לא נשלחו באותה גרסת npm) צמצמה את הסיכון. בחרנו ב-DeviceDescriptors.js בתור הקובץ הראשון, כי הוא היה אחד מהקבצים הפשוטים ביותר בקוד. יכול להיות שזה ייראה לכם קצת מאכזב לבצע את כל עבודת ההכנה הזו ולהגיע לשינוי קטן כל כך, אבל המטרה היא לא לבצע שינויים גדולים באופן מיידי, אלא להמשיך בזהירות ובאופן שיטתי, קובץ אחר קובץ. הזמן שמוקדש לאימות הגישה חוסך זמן בהמשך ההעברה, כשמגיעים לקבצים המורכבים יותר.

מוכיחים את התבנית וחוזר חלילה

למרבה המזל, השינוי ל-DeviceDescriptors.js עבר בהצלחה לקוד הבסיסי והתוכנית פעלה כמו שקיווינו. בשלב הזה אתם מוכנים להתחיל לעבוד, וזה בדיוק מה שעשינו. שימוש בתווית GitHub היא דרך נהדרת לקבץ יחד את כל בקשות המשיכה, וגילינו שהיא שימושית למעקב אחר ההתקדמות.

העברה של הנתונים ושיפורם בהמשך

התהליך שלנו בכל קובץ JavaScript היה:

  1. משנים את שם הקובץ מ-.js ל-.ts.
  2. מריצים את המהדר של TypeScript.
  3. פותרים את הבעיות.
  4. יוצרים את בקשת המשיכה.

רוב העבודה בבקשות ה-pull הראשוניות האלה הייתה לחלץ ממשקי TypeScript למבני נתונים קיימים. במקרה של בקשת ה-pull הראשונה שהעבירה את DeviceDescriptors.js שדיברנו עליה קודם, הקוד עבר מהמצב הבא:

module.exports = [
  { 
    name: 'Pixel 4',
    … // Other fields omitted to save space
  }, 
  …
]

והפך ל:

interface Device {
  name: string,
  …
}

const devices: Device[] = [{name: 'Pixel 4', …}, …]

module.exports = devices;

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

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

העברת הבדיקות כדי לבדוק את הגדרות הטיפוסים שלנו

אחרי שהעברנו את כל קוד המקור ל-TypeScript, יכולנו להתמקד בבדיקות. הבדיקות שלנו היו מכסות הרבה דברים, אבל כולן נכתבו ב-JavaScript. כלומר, הם לא בדקו את הגדרות הסוגים שלנו. אחת מהמטרות לטווח הארוך של הפרויקט (שאנחנו עדיין עובדים עליה) היא לשלוח הגדרות טיפוסים באיכות גבוהה מוכנות לשימוש עם Puppeteer, אבל לא היו לנו בדיקות בקוד לגבי הגדרות הטיפוסים שלנו.

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

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

הורדת הערוצים לתצוגה מקדימה

מומלץ להשתמש ב-Chrome Canary, ב-Dev או ב-Beta כדפדפן הפיתוח שמוגדר כברירת מחדל. ערוצי התצוגה המקדימה האלה מעניקים לכם גישה לתכונות העדכניות ביותר של DevTools, מאפשרים לכם לבדוק ממשקי API מתקדמים לפלטפורמות אינטרנט ולמצוא בעיות באתר לפני שהמשתמשים שלכם יעשו זאת.

יצירת קשר עם צוות כלי הפיתוח ל-Chrome

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