אנחנו מעריצים נלהבים של TypeScript בצוות כלי הפיתוח — עד כדי כך שנכתב בו קוד חדש בכלי הפיתוח, ואנחנו בעיצומו של תהליך העברה גדול של ה-codebase כולו לסימון הקלדה על ידי TypeScript. מידע נוסף על ההעברה הזו זמין בהרצאה שלנו בכנס Chrome Dev Summit 2020. לכן היה הגיוני להעביר גם את ה-codebase של Puppeteer ל-TypeScript.
תכנון המעבר
כשחשבנו איך לבצע את ההעברה, רצינו להיות מסוגלים להתקדם בצעדים קטנים. כך תוכלו למנוע את התקורה של המיגרציה - אתם עובדים רק על חלק קטן מהקוד בכל זמן - וכך להפחית גם את הסיכון. אם משהו משתבש באחד מהשלבים, אפשר לבטל את הפעולה בקלות. לבובת תיאטרון יש הרבה משתמשים, והתקנה פגומה תגרום לבעיות עבור רבים מהם, לכן היה חיוני שנמנע את הסיכון לפריצה של שינויים למינימום.
שמחנו גם שהמשחק של Puppeteer כולל ערכה חזקה של בדיקות יחידה, שכללו את כל הפונקציונליות שלו. במילים אחרות, אנחנו יכולים להיות בטוחים שלא התחלנו לעבוד עם הקוד במהלך ההעברה, אבל גם שלא ביצענו שינויים ב-API. מטרת המיגרציה הייתה להשלים אותה מבלי שהמשתמשים של ה-Puppeteer יידעו אפילו שאנחנו כבר עברנו, והבדיקות היו חלק חיוני מהאסטרטגיה הזו. אם לא היה לנו כיסוי בדיקות טוב, היינו מוסיפים אותו לפני שנמשיך בהעברה.
מסוכן לבצע שינוי כלשהו בקוד ללא בדיקות, אבל קיים סיכון גבוה במיוחד כשנוגעים בקבצים שלמים או בכל ה-codebase. כשמבצעים שינויים מכניים, קל לפספס שלב, ופעמים רבות הבדיקות זיהו בעיה שפספסה, הן מצד המיישם והן של הבודק.
אחד הדברים שהשקענו מראש הוא ההגדרה של אינטגרציה רציפה (CI). שמנו לב שהפעלות CI כנגד בקשות משיכה היו בעייתיות ולעיתים קרובות נכשלו. זה קרה כל כך הרבה, עד שהתרגלנו להתעלם מה-CI שלנו ולמזג את בקשות המשיכה בכל זאת, בהנחה שהכשל ב-CI הוא בעיה חד-פעמית ולא בעיה ב-Puppeteer.
לאחר זמן תחזוקה כללי וזמן ייעודי לתיקון בעיות בדיקה שגרתיות, העברנו את העניין למצב "עובר" בעקביות הרבה יותר, כך שיכולנו להקשיב ל-CI ולדעת שכשלון מצביע על בעיה אמיתית. העבודה הזאת לא מרשימה במיוחד, וזה מתסכל לצפות בהפעלות אינסופיות של CI, אבל היה חשוב שחבילת הבדיקות שלנו תפעל בצורה אמינה לאור מספר בקשות המשיכה שההעברה גרמה.
בוחרים קובץ אחד ומגיעים אליו
בשלב זה היה לנו מוכן לבצע את המיגרציה ושרת CI חזק מלא בבדיקות כדי לעקוב אחרינו. במקום להתמקד בקובץ שרירותי כלשהו, בחרנו בכוונה קובץ קטן להעברה. זהו תרגיל שימושי מכיוון שהוא מאפשר לך לאמת את התהליך המתוכנן שאתה עומד לבצע. אם הוא פועל בקובץ הזה, הגישה שלכם תקפה. אם לא, תוכלו לחזור ללוח השרטוט.
בנוסף, מעבר לכל קובץ בנפרד (ובגרסאות רגילות של Puppeteer, כך שכל השינויים לא נשלחו באותה גרסת npm) הפחיתו את הסיכון. בחרנו בקובץ DeviceDescriptors.js בתור הקובץ הראשון כי הוא היה אחד הקבצים הפשוטים ביותר ב-codebase. ביצוע כל עבודת ההכנה הזו עשוי להיות מאתגר למדי כדי לעשות שינוי כל כך קטן, אבל המטרה אינה לבצע שינויים ענקיים באופן מיידי, אלא להמשיך בזהירות ולפעול לפי כל קובץ באופן שיטתי. הזמן שהוקדש לאימות הגישה חוסך זמן בהמשך ההעברה, כאשר אתם נתקלים בקבצים המורכבים יותר האלה.
מוכיחים את הדפוס וחוזרים על הפעולה
למרבה המזל, השינוי של DeviceDescriptors.js נכנס בהצלחה ל-codebase, והתוכנית פעלה כפי שקיווינו. בשלב הזה אתם מוכנים 'כבר עכשיו', וזה בדיוק מה שעשינו. השימוש בתווית של GitHub הוא דרך מאוד נחמדה לקבץ את כל בקשות המשיכה יחד, וחשבנו שכדאי לעקוב אחרי ההתקדמות.
אפשר להעביר אותה ולשפר אותה מאוחר יותר
עבור כל קובץ JavaScript פרטי, התהליך שלנו היה:
- שינוי שם הקובץ מ-
.jsל-.ts. - מריצים את מהדר TypeScript.
- מתקנים בעיות.
- יוצרים את בקשת המשיכה.
רוב העבודה בבקשות המשיכה הראשוניות האלה הייתה לחלץ ממשקי TypeScript עבור מבני נתונים קיימים. במקרה של בקשת השליפה הראשונה שהעבירה את 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;
כחלק מהתהליך, עברנו על כל שורה ב-codebase כדי לבדוק אם יש בעיות. כמו בכל בסיס קוד (codebase) שנמצא כמה שנים וגדל עם הזמן, גם כאן יש תחומים שבהם ניתן לעצב מחדש את הקוד ולשפר את המצב. במיוחד בעקבות המעבר ל-TypeScript, ראינו מקומות שבהם שינוי קל של הקוד יאפשר לנו להסתמך יותר על המהדר ולשפר את בטיחות ההקלדה.
בניגוד לכך, חשוב מאוד להתנגד לביצוע השינויים האלה מיד. מטרת ההעברה היא להכניס את ה-codebase ל-TypeScript, ובכל זמן במהלך העברה גדולה, עליכם לחשוב על הסיכון לשיבושים בתוכנה ובמשתמשים שלכם. על ידי צמצום השינויים הראשוניים, שמרנו את הסיכון ברמה נמוכה. לאחר מיזוג הקובץ והעברתו ל-TypeScript, נוכל לבצע שינויים נוספים כדי לשפר את הקוד ולהשתמש במערכת הסוגים. חשוב להגדיר גבולות מחמירים להעברה ולנסות להישאר בהם.
העברת הבדיקות לבדיקת הגדרות הסוגים שלנו
אחרי שנעביר את קוד המקור כולו ל-TypeScript, נוכל להתמקד בבדיקות שלנו. הבדיקות שלנו כללו כיסוי נרחב, אבל כולן נכתבו ב-JavaScript. כלומר, דבר אחד שהם לא בדקו הוא הגדרות הסוגים שלנו. אחת המטרות לטווח הארוך של הפרויקט (שאנחנו עדיין עובדים עליה) היא לשלוח הגדרות של סוגים באיכות גבוהה עם Puppeteer, אבל לא בדיקות בבסיס הקוד שלנו לגבי הגדרות הסוגים.
על ידי העברת הבדיקות ל-TypeScript (לאחר אותו תהליך, מעבר קובץ אחר קובץ), מצאנו בעיות ב-TypeScript שלנו, שאחרת המשתמשים היו עלולים למצוא אותן. הבדיקות שלנו לא רק מכסות את כל הפונקציונליות שלנו, אלא גם משמשות כבדיקת איכות של TypeScript שלנו!
כבר הצלחנו להפיק תועלת רבה מ-TypeScript כמהנדסים שעבדו על בסיס הקוד של Puppeteer. בשילוב עם סביבת ה-CI המשופרת, אפשרו לנו להיות פרודוקטיביים יותר במהלך העבודה על Puppeteer ולגרום לבאגים של TypeScript לקליטה של באגים, שאחרת היו מגיעים לגרסה של npm. אנחנו שמחים לשלוח הגדרות TypeScript באיכות גבוהה כדי לאפשר לכל המפתחים המשתמשים ב-Puppeteer ליהנות גם הם מהעבודה הזו.
מורידים את הערוצים של התצוגה המקדימה.
כדאי להשתמש ב-Chrome Canary, Dev או בטא כדפדפן הפיתוח שמוגדר כברירת מחדל. ערוצי התצוגה המקדימה האלה מעניקים לך גישה לתכונות החדשות של כלי הפיתוח, בודקים ממשקי API מתקדמים של פלטפורמת האינטרנט ומוצאים בעיות באתר לפני שהמשתמשים נתקלים בבעיות!
יצירת קשר עם צוות כלי הפיתוח ל-Chrome
אפשר להשתמש באפשרויות הבאות כדי לדון בתכונות ובשינויים החדשים בפוסט, או בכל דבר אחר שקשור לכלי הפיתוח.
- שלחו לנו הצעה או משוב בכתובת crbug.com.
- כדי לדווח על בעיה בכלי הפיתוח, לוחצים על אפשרויות נוספות
> עזרה > דיווח על בעיות בכלי הפיתוח בכלי הפיתוח. - אפשר לשלוח ציוץ אל @ChromeDevTools.
- אפשר לכתוב תגובות לגבי 'מה חדש' בסרטוני YouTube או בקטע 'טיפים לשימוש בכלי הפיתוח' בסרטוני YouTube.