وتُعد خرائط المصدر أداة مهمة في تطوير الويب الحديث وتسهّل عملية تصحيح الأخطاء إلى حد كبير. تستكشف هذه الصفحة أساسيات خرائط المصدر وكيفية إنشائها وكيفية تحسينها لتجربة تصحيح الأخطاء.
الحاجة إلى خرائط المصادر
تم إنشاء تطبيقات الويب المبكرة بمستوى منخفض من التعقيد. كان المطوّرون ينشرون ملفات HTML وCSS وJavaScript على الويب مباشرةً.
قد تحتاج تطبيقات الويب الأكثر حداثة وتعقيدًا إلى مجموعة متنوعة من الأدوات في سير عمل التطوير. على سبيل المثال:
- لغات النماذج والمعالجات المسبقة لـ HTML: Pug، Nunjucks، Markdown.
- أدوات معالجة CSS المُسبَقة: SCSS، LESS، PostCSS
- أطر عمل JavaScript: Angular وReact وVue وSvelte.
- أُطر عمل JavaScript الوصفية: Next.js، Nuxt، Astro
- لغات البرمجة عالية المستوى: TypeScript، Dart، CoffeeScript
تتطلّب هذه الأدوات عملية إنشاء لنقل الرمز إلى HTML وJavaScript وCSS العادية التي يمكن للمتصفّحات فهمها. من الشائع أيضًا تحسين الأداء من خلال تصغير هذه الملفات ودمجها باستخدام أداة مثل Terser.
على سبيل المثال، باستخدام أدوات الإنشاء، يمكننا تحويل ملف 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
). ويمكن إنشاؤها باستخدام معظم أدوات الإنشاء
، بما في ذلك 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 أو الاطّلاع على خريطة المصدر.
يعرض عمود تم إنشاؤه على يمين الصفحة المحتوى المضغوط، ويعرض عمود الأصلي المصدر الأصلي.
يُشفِّر أداة العروض المرئية كل سطر في عمود الأصل باستخدام رمزه المطابق في عمود تم إنشاؤه.
يعرض قسم عمليات الربط عمليات الربط التي تم فك ترميزها للرمز. على سبيل المثال، يشير الرمز
65 -> 2:2
إلى ما يلي:
- الرمز المُنشَأ: تبدأ الكلمة
const
في الموضع 65 في المحتوى المضغوط. - الرمز الأصلي: تبدأ الكلمة
const
في السطر 2 والعمود 2 في المحتوى الأصلي.
يتيح ذلك للمطوّرين تحديد العلاقة بين الرمز المصغّر والرمز الأصلي بسرعة، ما يسهّل عملية تصحيح الأخطاء.
تطبّق أدوات مطوّري البرامج في المتصفّح خرائط المصدر هذه لمساعدتك في تحديد مشاكل تصحيح الأخطاء بسرعة في المتصفّح.
إضافات خريطة المصادر
تتوافق خرائط المصدر مع حقول الإضافات المخصّصة التي تبدأ بالبادئة x_
. ومن الأمثلة على ذلك حقل x_google_ignoreList
الذي تقترحه أدوات Chrome DevTools. اطّلِع على x_google_ignoreList
لمزيد من المعلومات حول كيفية مساعدة هذه الإضافات في التركيز على الرمز البرمجي.
عيوب خريطة المصادر
لا تكون عمليات ربط المصادر مكتملة دائمًا بالقدر الذي تحتاجه.
في المثال الأول، تمّ تحسين المتغيّر greet
أثناء عملية الإنشاء
، على الرغم من أنّ قيمته مضمّنة مباشرةً في ناتج السلسلة النهائي.
في هذه الحالة، عند تصحيح أخطاء الرمز البرمجي، قد لا تتمكّن أدوات المطوّرين من استنتاج القيمة الفعلية وعرضها. يمكن أن يجعل هذا النوع من الأخطاء عملية مراقبة رموذك البرمجية وتحليلها أكثر صعوبة.
هذه مشكلة يجب حلّها في تصميم خرائط المصدر. يتمثل أحد الحلول المحتملة في تضمين معلومات النطاق في خرائط المصدر بنفس الطريقة التي تفعل بها لغات البرمجة الأخرى مع معلومات تصحيح الأخطاء الخاصة بها.
ومع ذلك، يتطلّب ذلك أن يعمل النظام البيئي بأكمله معًا لتحسين مواصفات الخريطة المصدر وتنفيذها. لمتابعة الإجراءات الجارية لتحسين قابلية تصحيح الأخطاء باستخدام خرائط المصدر، يمكنك الرجوع إلى اقتراح الإصدار 4 من "خرائط Google" على GitHub.