מפות מקור הן כלי חיוני בפיתוח אינטרנט מודרני, שמקלות מאוד על ניפוי באגים. בדף הזה נסביר את היסודות של מפות המקור, איך הן נוצרות ואיך הן משפרים את חוויית ניפוי הבאגים.
הצורך במפות מקור
אפליקציות אינטרנט מוקדמות נבנו עם מורכבות נמוכה. מפתחים פרסו קובצי HTML, CSS ו-JavaScript ישירות באינטרנט.
לאפליקציות אינטרנט מודרניות ומורכבות יותר, יכול להיות שתצטרכו להשתמש במגוון כלים בתהליך הפיתוח שלהן. לדוגמה:
- שפות תבניות ומעבד קוד מקדים של HTML: Pug, Nunjucks, Markdown.
- מעבדי CSS: SCSS, LESS, PostCSS.
- מסגרות JavaScript: Angular, React, Vue, Svelte.
- מסגרות מטא של JavaScript: Next.js, Nuxt, Astro.
- שפות תכנות ברמה גבוהה: TypeScript, Dart, CoffeeScript.
לכלים האלה נדרש תהליך build כדי להעביר את הקוד ל-HTML סטנדרטי, JavaScript ו-CSS שהדפדפנים יכולים להבין. שיטה נפוצה נוספת היא לבצע אופטימיזציה של הביצועים על ידי צמצום הקבצים האלה ושילוב שלהם, באמצעות כלי כמו Terser.
לדוגמה, בעזרת כלי build אפשר להמיר ולדחוס את קובץ ה-TypeScript הבא לשורה אחת של JavaScript. אתם יכולים לנסות את זה בעצמכם בהדגמה הזו ב-GitHub.
/* A TypeScript demo: example.ts */
document.querySelector('button')?.addEventListener('click', () => {
const num: number = Math.floor(Math.random() * 101);
const greet: string = 'Hello';
(document.querySelector('p') as HTMLParagraphElement).innerText = `${greet}, you are no. ${num}!`;
console.log(num);
});
גרסה דחוסה תהיה:
/* A compressed JavaScript version of the TypeScript demo: example.min.js */
document.querySelector("button")?.addEventListener("click",(()=>{const e=Math.floor(101*Math.random());document.querySelector("p").innerText=`Hello, you are no. ${e}!`,console.log(e)}));
עם זאת, דחיסת הקוד עלולה להקשות על ניפוי הבאגים. מפות מקור יכולות לפתור את הבעיה הזו: הן מאפשרות למפות את הקוד המהדרר בחזרה לקוד המקורי, וכך עוזרות לכם למצוא במהירות את מקור השגיאה.
יצירת מפות מקור
מפות מקור הן קבצים ששמותיהם מסתיימים ב-.map
(לדוגמה, example.min.js.map
ו-styles.css.map
). אפשר ליצור אותן באמצעות רוב כלי ה-build, כולל Vite, webpack, Rollup, Parcel ו-esbuild.
חלק מהכלים כוללים מפות מקור כברירת מחדל. יכול להיות שאחרים יצטרכו הגדרות נוספות כדי ליצור אותם:
/* Example configuration: vite.config.js */
/* https://vitejs.dev/config/ */
export default defineConfig({
build: {
sourcemap: true, // enable production source maps
},
css: {
devSourcemap: true // enable CSS source maps during development
}
})
הסבר על מפת המקור
כדי לעזור בניפוי באגים, קובצי מפת המקור האלה מכילים מידע חיוני על האופן שבו הקוד המהדר ממופה לקוד המקורי. דוגמה למיפוי מקור:
{
"mappings": "AAAAA,SAASC,cAAc,WAAWC, ...",
"sources": ["src/script.ts"],
"sourcesContent": ["document.querySelector('button')..."],
"names": ["document","querySelector", ...],
"version": 3,
"file": "example.min.js.map"
}
כדי להבין כל אחד מהשדות האלה, תוכלו לקרוא את המפרט של מפת המקור או את האנטומיה של מפת מקור.
השדה mappings
הוא החלק החשוב ביותר במפת מקור. הוא משתמש במחרוזת מקודדת של VLQ base 64 כדי למפות שורות ומיקומים בקובץ המהדרג לקובץ המקורי התואם. אפשר להציג את המיפוי הזה באמצעות כלי להצגה חזותית של מפת מקור, כמו source-map-visualization או Source Map Visualization.
בעמודה נוצרה בצד שמאל מוצג התוכן הדחוס, ובעמודה המקורי מוצג המקור המקורי.
בכל שורה בעמודה original מוצג קוד צבע שמתאים לקוד שמוצג בעמודה generated.
בקטע mappings מוצגים מיפויים מפוענחים של הקוד. לדוגמה, הערך 65 -> 2:2
מציין:
- קוד נוצר: המילה
const
מתחילה במיקום 65 בתוכן הנדחס. - קוד מקורי: המילה
const
מתחילה בשורה 2 ובעמודה 2 בתוכן המקורי.
כך המפתחים יכולים לזהות במהירות את הקשר בין הקוד הממוזער לקוד המקורי, וכך תהליך ניפוי הבאגים נעשה חלק יותר.
כלים למפתחי דפדפנים מיישמים את מפות המקור האלה כדי לעזור לכם לאתר במהירות את הבעיות בניפוי הבאגים בדפדפן.
תוספי מפות מקור
במפות מקור יש תמיכה בשדות תוספים מותאמים אישית שמתחילים בקידומת x_
. דוגמה אחת היא השדה x_google_ignoreList
של התוסף שמוצע על ידי כלי הפיתוח ל-Chrome. במאמר x_google_ignoreList מוסבר איך התוספים האלה עוזרים לכם להתמקד בקוד.
החסרונות של מפת מקור
לצערנו, מיפויי המקורות לא תמיד מלאים כפי שצריך.
בדוגמה הראשונה, המשתנה greet
הושמט במהלך תהליך ה-build, למרות שהערך שלו מוטמע ישירות בפלט המחרוזת הסופי.
במקרה כזה, כשמנסים לנפות באגים בקוד, יכול להיות שכלי הפיתוח לא יוכלו להסיק את הערך בפועל ולהציג אותו. שגיאות כאלה עלולות להקשות על המעקב אחרי הקוד ועל הניתוח שלו.
זו בעיה שצריך לפתור במסגרת העיצוב של מפות המקור. פתרון אפשרי אחד הוא לכלול את פרטי ההיקף במפות המקור, בדומה לשפות תכנות אחרות שמוסיפות את פרטי ניפוי הבאגים שלהן.
עם זאת, כדי לעשות את זה, כל הסביבה העסקית צריכה לפעול יחד כדי לשפר את המפרט וההטמעה של מפת המקור. כדי לעקוב אחרי השיפורים המתמשכים ביכולת לנפות באגים באמצעות מפות מקור, אפשר לעיין בהצעה ל-Source Maps v4 ב-GitHub.