בחירה והגדרה של כלי ה-build על סמך שיטות מומלצות.
היום web.dev משיק יוזמה חדשה בשם tooling.report. זהו אתר שמספק למפתחי אתרים סקירה כללית של התכונות שנתמכות במגוון כלי פיתוח פופולריים. בנינו את האתר הזה כדי לעזור לכם לבחור את כלי ה-build המתאים לפרויקט הבא, להחליט אם כדאי לעבור מכלי אחד לאחר או להבין איך לשלב את השיטות המומלצות בהגדרות של הכלים ובבסיס הקוד. לכלים יש תחומי התמקדות שונים והם מיועדים למגוון צרכים, כך שכדי לבחור ולהגדיר כלים צריך לבצע עסקאות. בעזרת Tooling.report, אנחנו שואפים להסביר את החסרונות האלה ולתעד את השיטות המומלצות לעבודה עם כל כלי build נתון.
נשמע מרגש? היכנסו לאתר Tooling.report כדי להתחיל לחקור אותו, או המשיכו לקרוא כדי ללמוד מדוע פיתחנו את האתר הזה.
כלים לפיתוח כלים בדרך כלל מפריעות לנו
ב-GoogleChromeLabs, פיתחנו אפליקציות אינטרנט כמו Squoosh ו-Proxx, וגם אתרים כמו האפליקציה של Chrome Dev Summit 2019. כמו בכל פרויקט של פיתוח אתרים, בדרך כלל אנחנו מתחילים בדיון על תשתיות הפרויקט, כמו סביבת האירוח, ה-frameworks והגדרת כלי ה-build. התשתית הזו מתעדכנת עם התקדמות הפרויקט: מתווספים יישומי פלאגין חדשים כדי להתאים למסגרות או לשיטות שאנחנו משתמשים בהן, או שאופן כתיבת הקוד משתנה כדי שכלי ה-build שלנו יבינו טוב יותר מה אנחנו מנסים להשיג. לאורך התהליך הזה גילינו לעתים קרובות שהכלים שבחרתם משבשים אותנו בסופו של דבר.
הצוות שלנו מתמקד ביצירת חוויית האינטרנט הטובה ביותר למשתמשים, וכתוצאה מכך לעיתים קרובות מתבצע שיפור בהרכבה ובמשלוח של הנכסים בממשק הקצה. לדוגמה, אם יחסי התלות היו משותפים בין לסקריפט של thread ראשי ולסקריפט של Web worker, לכן כדאי להוריד את יחסי התלות פעם אחת במקום לאחד אותם פעמיים בכל סקריפט. חלק מהכלים תומכים בכך, ויש כלים שמצריכים מאמץ משמעותי בהתאמה אישית כדי לשנות את התנהגויות ברירת המחדל, ובאחרים אי אפשר לעשות זאת.
בעקבות הניסיון הזה, בדקנו מה כלי build שונים יכולים ולא יכולים לעשות. קיווינו ליצור רשימת משימות לתכונות כדי שבפעם הבאה שנתחיל פרויקט חדש, נוכל להעריך ולבחור איזה כלי הכי מתאים לפרויקט שלנו.
הגישה שלנו
איך אנחנו יכולים להעריך ולהשוות כלי build שונים במקום אחד? ניגשנו לזה על ידי כתיבת תרחישי בדיקה.
הצוות שלנו דיבר ותכנן קריטריונים לבדיקה שלדעתנו מייצגים שיטות מומלצות לפיתוח באינטרנט. התמקדנו במיוחד ביצירת חוויית משתמש מהירה, רספונסיבית וחלקה, תוך החרגה מכוונת של בדיקות שקשורות לחוויית המפתחים כדי להימנע ממדידה של שתי תוצאות שלא ניתן להשוות ביניהן.
אחרי שיצרתם את רשימת הבדיקות, כתבנו סקריפט build לכל אחד מהכלים כדי לבדוק אם הכלי יכול לעמוד בקריטריונים להצלחה של הבדיקה. בשלב הראשון, החלטנו לחקור את חבילת האינטרנט v4, Rollup v2 ו-Parcel v2. בדקנו גם את Browserify + Gulp מכיוון שמספר רב של פרויקטים עדיין משתמשים בהגדרה הזו. כדי שהבדיקה תעבור את הבדיקה, אפשר להשתמש רק בתכונות של הכלי או בפלאגין של הכלי שמתועדות באופן ציבורי. אחרי שנכתבה קבוצת הבדיקות הראשונית, עבדנו עם המחברים של כלי ה-build כדי לוודא שאנחנו משתמשים בכלים שלהם בצורה נכונה ומייצגים אותם בצורה הוגנת.
אנחנו משתמשים רק ב-${tool_name}. האם זה עדיין יהיה מעניין?
בצוותים רבים יש אנשים שתפקידם לתחזוקה של תשתית ה-build, ויכול להיות שחברים אחרים בצוות לא יצטרכו לבחור בעצמם בכל הקשור לבניית כלים. אנחנו מקווים שהאתר ימשיך להיות שימושי גם לכם, כדרך להגדיר ציפיות לכלים שעליהם אתם מסתמכים. לכל בדיקה הוספנו הסבר למה הבדיקה חשובה ומקורות נוספים. ואם אתם רוצים ליישם שיטה מומלצת בכלי לבחירתכם, הגדרות הבדיקה במאגר שלנו מכילות את קובצי התצורה שדרושים לשם כך.
האם אני יכול לתרום לאתר?
אם לדעתכם צריך לבדוק תכונה מסוימת שחסרה כרגע, תוכלו להציע אותה בבעיה ב-GitHub כדי להתחיל את הדיון. המטרה שלנו היא לכלול תרחישים לדוגמה מהעולם האמיתי, וכל בדיקה נוספת להערכה טובה יותר של התוצאות האלה תתקבל בברכה.
אם תרצו לכתוב בדיקות לכלים שלא כללנו בהגדרה הראשונית, נשמח גם לכך! למידע נוסף, ראו CONTRIBUTING.md.