תנו ל-npm לבחור את הרשומה לפי היקף החבילה, לא לפי ה-VPN

התחברות ל-VPN לא אמורה להיות כרוכה בעריכת הגדרת הרשומה של npm פעמיים ביום. רשומת היקף בקובץ תצורה ברמת הפרויקט יכולה לשלוח את חבילות החברה לרשומה אחת ואת כל השאר לזו הציבורית, בלי החלפות ובלי עקיפה שנשארת מאחור בשישי אחר הצהריים. הבעיה היא שזה פותר רק את השמות; ניתוב, אישורים וקדימות תצורה הם שלושה דברים נפרדים שכל אחד נכשל בדרכו.

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

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

לכן הקובץ שלמטה מבטא שתי כוונות בשלוש שורות: חבילות ציבוריות הולכות לרשומה הציבורית, וחבילות תחת היקף החברה הולכות לרשומת החברה עם אסימון עבור המארח הזה.

registry=https://registry.npmjs.org/
@acme:registry=https://packages.corp.example/
//packages.corp.example/:_authToken=${NPM_TOKEN}

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

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

כתבו את הקובץ בסדר הנכון

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

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

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

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

אישורים שייכים למארח, לא לפרויקט

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

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

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

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

כשהרשומה הלא נכונה מנצחת

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

משתנה הסביבה הוא החשוד הרגיל ב-CI, שבו משימה מגדירה את הרשומה פעם אחת וכל שלב אחר יורש אותה. השני הנפוץ ביותר הוא קובץ ברמת משתמש במכונה של מפתח שמעקף את מה שהמאגר אומר.

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

רשימת בדיקה לפני ביצוע

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

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

לאחר מכן ודאו את ההתנהגות ב-checkout נקי בלי חבילות במטמון. התקנה טרייה היא הבדיקה היחידה שמראה מה עמית חדש יחווה.