הוספת לינטר ל-commit messages

הערה: ברוב המאמרים שלי אני משתדל לכתוב פשוט יחסית ולהתחיל מההתחלה. המאמר הזה מיועד למפתחים מנוסים יותר אז ההנחה שלי היא שאתם מכירים git (אם לא, זה הזמן ללמוד ותתחילו פה) ומונחים אחרים. שמתי קישורים שמסבירים מונחים פחות מוכרים. אם זה נראה לכם כמו ג׳יבריש כי אני זורק פה דברים שאתם לא מכירים, עקבו וקראו את הפוסטים שיש קישורים וחיזרו למאמר הזה אחר כך.

אני משוגע על לינטרים, שזה ניתוח קוד סטטי. מה זה? זה כלי שבודק תקינות קוד במגוון דרכים. למשל רווחים בין פונקציה לפונקציה, שמות וקונבנצית שמות וגם דברים רציניים יותר – למשל בדיקה שלא תקעתם איזה XSS מביך. בעבר משהו שהיה שמור רק לשפות צד שרת אבל כבר ממש לא. אם יצא לכם לכתוב קצת ריאקט, אנגולר או vue אתם בוודאי מכירים את זה – זה תהליך שרץ ובודק תקינות קוד וכבר מוטמע בכל ה-create react app ודומיהן. אני שם את זה כחלק מתהליך הבילד שלי ומבצע את הבדיקות. כתבתי על eslint, שזה הכלי המרכזי לבדיקות קוד של ג׳אווהסקריפט.

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

רציתי לכתוב כמה מילים על בדיקת תקינות של commit messages. הדבר הראשון שצריך לשאול הוא למה לעזאזל לבצע בדיקות תקינות על commit message? בשיטת הפיתוח שאני עובד לפיה – אנו עושים squash. מה זה אומר? שבפועל לא רואים בכלל את כל ההודעות האלו. זה משהו פרטי לחלוטין וכך מתייחסים אליו. מה שרואים זה את הפול ריקווסט ועל זה מקפידים. אם אתם עובדים בשיטה הזו, זה באמת לא רלוונטי.

א-ב-ל

יש לנו כל מיני כלים שדווקא כן עושים שימוש ב-commit message. למשל lerna. שהוא כלי לניהול מונוריפו שמגיע לו פוסט משלו. בכל מקרה, lerna כן מסתכל על ה-commit messages וכאשר אנו עושים דיפלוי, הוא משנה את הגרסה אוטומטית. כך למשל, אם יש לי 4 חבילות: package1, package2, package3, package4 – שיניתי את השניה ואז אני רוצה לעדכן אותה, אני יכול לעשות את זה ידנית או לחלופין, להכניס ל-commit message את הטקסט הזה:

chore(package2) patch

בתהליך הבילד, אם lerna קולטת את הטקסט הזה, היא לוקחת את package2 ומעלה את הגרסה שלו ב-patch (כתבתי פה על גרסאות למי שלא מבין מאיפה נפלתי עליו). זה מעולה, אבל מה קורה אם כתבתי בטעות (למשל) משהו כזה?

chore(pacakge2) patch

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

כמובן שהבדיקה הזו יכולה להעשות במחשב המקומי בלבד. זה לא עסק של הבילד איך אני בוחר לעשות commit message ואני יכול לעקוף את הלינט עם no-verify. אבל זה ימנע ממני וממפתחים אחרים ליפול בפח יקוש.

את הלינטר הזה עושים עם lint commit message – שהוא ממש ממש קל להתקנה. הוא מגיע עם presets ומגדירים אותו בקלות רבה. כך הוא מוגדר באחד הפרויקטים שלי. שימו לב שהשתמשתי ב-husky כדי לדאוג שהתהליך ירוץ מקומית לפני כל commit (אם אתם לא מכירים את husky אז מומלץ לקרוא פה)

  "devDependencies": {
    "@commitlint/cli": "9.0.1",
    "@commitlint/config-conventional": "9.0.1",
    "@commitlint/config-lerna-scopes": "9.0.1",
    "husky": "4.2.5",
    "lerna": "^3.20.2"
  },
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },

קובץ ההגדרות נמצא ב-commitlint.config.js והוא נראה כך:

module.exports = { extends: ['@commitlint/config-lerna-scopes', '@commitlint/config-conventional'] };

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

וזהו! זה חוסך כאב ראש במצבים כאלו. לא הייתי משתמש בלינטר ל-commit messages במקומות אחרים, אבל אם יש לכם כלים שנסמכים על ה-commit messages, יישום של לינטר כזה בבילד מקומית יכול לסייע מאוד.