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

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

import getConfig from 'next/config'
import Image from 'next/image'

// Only holds serverRuntimeConfig and publicRuntimeConfig
const { serverRuntimeConfig, publicRuntimeConfig } = getConfig()
// Will only be available on the server-side
console.log(serverRuntimeConfig.mySecret)
// Will be available on both server-side and client-side
console.log(publicRuntimeConfig.staticFolder)

function MyImage() {
  return (
    <div>
      <Image
        src={`${publicRuntimeConfig.staticFolder}/logo.png`}
        alt="logo"
        layout="fill"
      />
    </div>
  )
}

export default MyImage

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

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

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