ข้อมูลเบื้องต้นเกี่ยวกับการแมปแหล่งที่มา JavaScript

เคยไหมที่คุณอยากให้คุณทำให้โค้ดฝั่งไคลเอ็นต์อ่านได้และแก้ไขข้อบกพร่องที่สำคัญกว่า แม้จะรวมและลดขนาดลงแล้วก็ตามโดยไม่ส่งผลกระทบต่อประสิทธิภาพ ตอนนี้คุณสามารถผ่านความมหัศจรรย์ของแผนที่แหล่งที่มาได้แล้ว

การแมปแหล่งที่มาคือวิธีแมปไฟล์แบบรวม/แบบย่อกลับไปเป็นสถานะที่ยังไม่ได้สร้าง เมื่อคุณสร้างสำหรับเวอร์ชันที่ใช้งานจริง รวมถึงการลดขนาดและรวมไฟล์ JavaScript คุณจะสร้างแผนที่แหล่งที่มาซึ่งมีข้อมูลเกี่ยวกับไฟล์ต้นฉบับของคุณ เมื่อคุณค้นหาหมายเลขบรรทัดและคอลัมน์ใน JavaScript ที่สร้างขึ้น คุณสามารถทำการค้นหาในแผนที่แหล่งที่มาซึ่งแสดงตำแหน่งเดิมได้ เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ (ในขณะนี้คือ WebKit Nightly เวอร์ชัน, Google Chrome หรือ Firefox 23 ขึ้นไป) สามารถแยกวิเคราะห์แผนที่แหล่งที่มาโดยอัตโนมัติและทำให้ดูเหมือนว่าคุณกำลังเรียกใช้ไฟล์ที่ไม่มีการบีบอัดและไม่ได้รวมเข้าด้วยกัน

การสาธิตจะให้คุณคลิกขวาที่ใดก็ได้ในพื้นที่ข้อความที่มีแหล่งที่มาที่สร้างขึ้น เลือก "รับตำแหน่งเดิม" จะค้นหาการแมปแหล่งที่มาโดยการส่งผ่านในบรรทัดและหมายเลขคอลัมน์ที่สร้างขึ้น แล้วส่งกลับตำแหน่งในโค้ดเดิม ตรวจสอบว่าคอนโซลเปิดอยู่เพื่อให้เห็นผลลัพธ์

โลกแห่งความเป็นจริง

ก่อนที่คุณจะดูการใช้งานแผนที่แหล่งที่มาในการใช้งานจริงต่อไปนี้ โปรดตรวจสอบว่าคุณได้เปิดใช้งานคุณลักษณะแผนที่แหล่งที่มาใน Chrome Canary หรือ WebKit ทุกคืนโดยคลิกเฟืองการตั้งค่าในแผงเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ และเลือกตัวเลือก "เปิดใช้แผนที่แหล่งที่มา"

Firefox 23+ มีแผนที่ต้นฉบับที่เปิดใช้งานโดยค่าเริ่มต้นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ในตัว

เหตุใดฉันจึงควรสนใจการแมปแหล่งที่มา

ขณะนี้การแมปแหล่งที่มาจะทำงานได้ระหว่าง JavaScript ที่ไม่ได้บีบอัด/แบบรวมกับ JavaScript ที่บีบอัด/ไม่รวมเข้าด้วยกันเท่านั้น แต่อนาคตก็ดูจะสดใสจากการพูดคุยเกี่ยวกับภาษาที่คอมไพล์เป็น JavaScript เช่น CoffeeScript และความเป็นไปได้ที่จะเพิ่มการรองรับตัวประมวลผล CSS ล่วงหน้า เช่น SASS หรือ LESS

ในอนาคต เราสามารถใช้ภาษาเกือบทุกภาษาได้ง่ายๆ ราวกับว่ามีการรองรับในเบราว์เซอร์ที่มีแผนที่แหล่งที่มาอยู่แล้ว ดังนี้

• CoffeeScript
• ECMAScript 6 ขึ้นไป
• SASS/LESS และอื่นๆ
• แทบจะทุกภาษาที่คอมไพล์เป็น JavaScript

ลองดู Screencast ของ CoffeeScript นี้ที่มีการแก้ไขข้อบกพร่องในรุ่นทดลองของคอนโซล Firefox

เมื่อเร็วๆ นี้ Google Web Toolkit (GWT) ได้เพิ่มการสนับสนุนสำหรับการแมปแหล่งที่มา Ray Cromwell จากทีม GWT ทำ Screencast ที่ยอดเยี่ยมเพื่อแสดงการสนับสนุนแผนที่แหล่งที่มาในการใช้งานจริง

อีกตัวอย่างหนึ่งที่ผมได้รวบรวมไว้ใช้ไลบรารี Traceur ของ Google ซึ่งช่วยให้คุณสามารถเขียน ES6 (ECMAScript 6 หรือ Next) และคอมไพล์เป็นโค้ดที่ใช้ร่วมกับ ES3 ได้ คอมไพเลอร์ Traceur ยังจะสร้างแผนที่แหล่งที่มาอีกด้วย ดูการสาธิตเกี่ยวกับลักษณะและคลาส ES6 ที่มีการใช้งานราวกับได้รับการรองรับในเบราว์เซอร์ตั้งแต่แรก สืบเนื่องจากการแมปแหล่งที่มา

พื้นที่ข้อความในการสาธิตยังช่วยให้คุณเขียน ES6 ซึ่งจะมีการคอมไพล์ได้ทันที และสร้างการแมปแหล่งที่มาพร้อมกับโค้ด ES3 ที่เทียบเท่ากัน

การสาธิต: เขียน ES6, แก้ไขข้อบกพร่อง, ดูการแมปแหล่งที่มาในการใช้งานจริง

การแมปแหล่งที่มาทำงานอย่างไร

คอมไพเลอร์/ตัวจำกัด JavaScript เพียงตัวเดียวที่มีการสนับสนุนสำหรับการสร้างแผนที่แหล่งที่มาคือคอมไพเลอร์ Closure (ฉันจะอธิบายวิธีการใช้งานในภายหลัง) เมื่อคุณได้รวมและลดขนาด JavaScript แล้ว ไฟล์การแมปแหล่งที่มาจะมีไฟล์การแมปแหล่งที่มาอยู่

ปัจจุบันคอมไพเลอร์ Closure ไม่ได้เพิ่มความคิดเห็นพิเศษในตอนท้ายที่จำเป็น เพื่อแสดงถึงเครื่องมือสำหรับนักพัฒนาเบราว์เซอร์ที่มีการแมปแหล่งที่มาให้ใช้งาน

//# sourceMappingURL=/path/to/file.js.map

ซึ่งทำให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์แมปการเรียกกลับไปยังตำแหน่งของตนในไฟล์ต้นฉบับต้นฉบับได้ ก่อนหน้านี้ Pragma สำหรับความคิดเห็นคือ //@ แต่เนื่องจากปัญหาบางอย่างเกี่ยวกับเรื่องนี้และการรวบรวมความคิดเห็นแบบมีเงื่อนไขของ IE จึงได้ตัดสินใจให้เปลี่ยนเป็น //# ปัจจุบัน Chrome Canary, WebKit Nightly และ Firefox 24+ รองรับการทำงานของความคิดเห็นแบบใหม่ การเปลี่ยนแปลงไวยากรณ์นี้ยังมีผลกับ sourceURL ด้วย

หากไม่ชอบความคิดเห็นแปลกๆ นี้ คุณสามารถเลือกกำหนดส่วนหัวพิเศษในไฟล์ JavaScript ที่คอมไพล์ได้ โดยทำดังนี้

X-SourceMap: /path/to/file.js.map

เช่นเดียวกับความคิดเห็น ข้อมูลนี้จะเป็นตัวบอกให้ผู้บริโภคการแมปแหล่งที่มาทราบว่าจะค้นหาการแมปแหล่งที่มาที่เชื่อมโยงกับไฟล์ JavaScript ได้จากที่ใด ส่วนหัวนี้ยังช่วยแก้ปัญหาการอ้างอิงการแมปแหล่งที่มาในภาษาที่ไม่รองรับความคิดเห็นบรรทัดเดียวได้อีกด้วย

ระบบจะดาวน์โหลดไฟล์แผนที่ต้นฉบับต่อเมื่อคุณเปิดใช้แผนที่แหล่งที่มาและเปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ไว้ นอกจากนี้คุณจะต้องอัปโหลดไฟล์ต้นฉบับเพื่อให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์อ้างอิงและแสดงไฟล์ดังกล่าวได้เมื่อจำเป็น

ฉันจะสร้างการแมปแหล่งที่มาได้อย่างไร

คุณจะต้องใช้คอมไพเลอร์การปิดเพื่อลดขนาด เชื่อมต่อ และสร้างการแมปแหล่งที่มาสำหรับไฟล์ JavaScript ของคุณ คำสั่งมีดังนี้

java -jar compiler.jar \
--js script.js \
--create_source_map ./script-min.js.map \
--source_map_format=V3 \
--js_output_file script-min.js

แฟล็กคำสั่งที่สำคัญ 2 อย่างคือ --create_source_map และ --source_map_format ซึ่งจำเป็นเนื่องจากเวอร์ชันเริ่มต้นคือเวอร์ชัน 2 และเราต้องการใช้เวอร์ชัน 3 เท่านั้น

โครงสร้างของการแมปแหล่งที่มา

เพื่อให้เข้าใจการแมปแหล่งที่มามากขึ้น เราจะยกตัวอย่างเล็กๆ ของไฟล์แผนที่แหล่งที่มาที่คอมไพเลอร์ Closure สร้างขึ้น และเจาะลึกรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการทำงานของส่วน "การแมป" ตัวอย่างต่อไปนี้คือความแตกต่างเล็กน้อยจากตัวอย่างข้อมูลจำเพาะ V3

{
    version : 3,
    file: "out.js",
    sourceRoot : "",
    sources: ["foo.js", "bar.js"],
    names: ["src", "maps", "are", "fun"],
    mappings: "AAgBC,SAAQ,CAAEA"
}

ที่ด้านบนคุณจะเห็นว่าแผนที่แหล่งที่มาเป็นวัตถุจริงที่มีข้อมูลที่น่าสนใจอยู่มากมาย ดังนี้

• หมายเลขเวอร์ชันที่การแมปแหล่งที่มาอิงตาม
• ชื่อไฟล์ของโค้ดที่สร้างขึ้น (ไฟล์ที่สร้างขึ้นเล็ก/รวมเวอร์ชันที่ใช้งานจริง)
• sourceRoot ให้คุณเพิ่มโครงสร้างโฟลเดอร์ไว้ข้างหน้าแหล่งที่มา ซึ่งก็เป็นเทคนิคการประหยัดพื้นที่เช่นกัน
• แหล่งที่มามีชื่อไฟล์ทั้งหมดที่รวมเข้าด้วยกัน
• ชื่อ ประกอบด้วยชื่อตัวแปร/เมธอดทั้งหมดที่ปรากฏตลอดโค้ดของคุณ
• สุดท้าย พร็อพเพอร์ตี้การแมปคือจุดที่น่าสนใจเมื่อใช้ค่า Base64 VLQ คุณประหยัดพื้นที่จริงๆ ได้ที่นี่

Base64 VLQ และทำให้การแมปแหล่งที่มามีขนาดเล็ก

เริ่มแรก ข้อกำหนดแผนที่ต้นฉบับมีเอาต์พุตแบบละเอียดมากสำหรับการแมปทั้งหมด และส่งผลให้การแมปแหล่งที่มามีขนาดมากกว่าโค้ดที่สร้างขึ้นประมาณ 10 เท่า เวอร์ชัน 2 ลดจำนวนนั้นลงได้ประมาณ 50% และเวอร์ชัน 3 ลดขนาดลงอีกครั้งอีก 50% ดังนั้นสำหรับไฟล์ขนาด 133 KB คุณจะได้รับการแมปแหล่งที่มาขนาดประมาณ 300 KB

พวกเขาลดขนาดในขณะที่ยังคงรักษาการแมปที่ซับซ้อนได้อย่างไร

ระบบจะใช้ VLQ (จำนวนตัวแปรความยาว) พร้อมกับการเข้ารหัสค่าเป็นค่า Base64 พร็อพเพอร์ตี้การแมปเป็นสตริงขนาดใหญ่มาก สตริงนี้มีเครื่องหมายเซมิโคลอน (;) ที่แสดงหมายเลขบรรทัดภายในไฟล์ที่สร้างขึ้น แต่ละบรรทัดจะมีเครื่องหมายจุลภาค (,) ที่ใช้แทนแต่ละเซกเมนต์ภายในบรรทัดนั้นๆ แต่ละกลุ่มเหล่านี้เป็น 1, 4 หรือ 5 ในฟิลด์ที่มีความยาวแปรผันได้ URL บางรายการอาจปรากฏยาวกว่านี้ แต่ยังมีบิตความต่อเนื่อง แต่ละส่วนสร้างขึ้นจากส่วนก่อนหน้า ซึ่งช่วยลดขนาดไฟล์เนื่องจากแต่ละบิตสัมพันธ์กับส่วนก่อนหน้า

ดังที่กล่าวไว้ข้างต้น แต่ละกลุ่มสามารถมีความยาวแปรผันได้ 1, 4 หรือ 5 ส่วน แผนภาพนี้ถือว่าเป็นความยาวแปรผันที่ 4 โดยมีบิตต่อ 1 บิต (g) เราจะแจกแจงส่วนของถนนนี้ และแสดงให้คุณเห็นว่าแผนที่แหล่งที่มาจะทำงานกับตำแหน่งเดิมอย่างไร

ค่าที่แสดงด้านบนเป็นค่าที่ถอดรหัสแล้วของ Base64 เท่านั้น ยังมีการประมวลผลเพิ่มเติมเพื่อให้ได้ค่าที่แท้จริง โดยปกติแต่ละกลุ่มจะทำงาน 5 อย่าง ได้แก่

• คอลัมน์ที่สร้างแล้ว
• ไฟล์ต้นฉบับที่มีไฟล์นี้
• หมายเลขบรรทัดเดิม
• คอลัมน์เดิม
• และชื่อเดิม หากมี

บางกลุ่มไม่ได้มีชื่อ ชื่อเมธอด หรืออาร์กิวเมนต์ ดังนั้นทุกกลุ่มจะสลับไปมาระหว่างความยาวตัวแปร 4-5 ตัวแปร ค่า g ในไดอะแกรมกลุ่มด้านบนคือสิ่งที่เรียกว่าบิตความต่อเนื่อง ซึ่งจะช่วยให้เพิ่มประสิทธิภาพได้มากขึ้นในขั้นตอนการถอดรหัส Base64 VLQ เครื่องมือแบบต่อไปเรื่อยๆ ช่วยให้คุณสร้างค่ากลุ่มเพื่อจัดเก็บตัวเลขจำนวนมากโดยไม่ต้องเก็บตัวเลขจำนวนมากได้ ซึ่งเป็นเทคนิคการประหยัดพื้นที่ที่ชาญฉลาดซึ่งมีรากมาจากรูปแบบ MIDI

เมื่อประมวลผลเพิ่มเติมแล้ว แผนภาพข้างต้น AAgBC จะแสดงผล 0, 0, 32, 16, 1 โดย 32 คือบิตต่อที่ช่วยสร้างค่า 16 ดังต่อไปนี้ B ที่ถอดรหัสใน Base64 เท่านั้นคือ 1 ดังนั้นค่าสำคัญที่ใช้คือ 0, 0, 16, 1 ซึ่งทำให้เราทราบว่าบรรทัดที่ 1 (บรรทัดนี้จะนับด้วยเครื่องหมายเซมิโคลอน) คอลัมน์ 0 ของไฟล์ที่สร้างขึ้นแมปกับไฟล์ 0 (อาร์เรย์ของไฟล์ 0 คือ foo.js) บรรทัดที่ 16 ที่คอลัมน์ 1

ฉันจะอ้างอิงไลบรารี JavaScript การแมปแหล่งที่มาของ Mozilla เพื่อแสดงวิธีถอดรหัสเซกเมนต์ คุณสามารถดูโค้ดการแมปแหล่งที่มาของเครื่องมือสำหรับนักพัฒนา WebKit ที่เขียนด้วย JavaScript ได้อีกด้วย

เราจําเป็นต้องมีความเข้าใจเบื้องต้นเกี่ยวกับโอเปอเรเตอร์บิตไวส์และวิธีการทำงานของข้อกำหนดสำหรับการแมปแหล่งที่มา เพื่อให้เข้าใจว่าเราได้ค่า 16 จาก B มาอย่างไร ตัวเลขก่อนหน้า g มีค่าสถานะเป็นบิตต่อด้วยการเปรียบเทียบตัวเลข (32) และ VLQ_CONTINUATION_BIT (ไบนารี 100000 หรือ 32) โดยใช้โอเปอเรเตอร์บิตไวส์ AND (&)

32 & 32 = 32
// or
100000
|
|
V
100000

ซึ่งจะแสดงเลข 1 ในแต่ละตําแหน่งที่บิตทั้ง 2 ปรากฏขึ้น ดังนั้น ค่าที่ถอดรหัสของ Base64 ของ 33 & 32 จะแสดงผลเป็น 32 เนื่องจากจะใช้ตำแหน่งแบบ 32 บิตร่วมกันเท่านั้นตามที่คุณเห็นในแผนภาพด้านบน ซึ่งจะเพิ่มค่า Shift ของบิตดังกล่าวขึ้นอีก 5 บิตสำหรับบิตที่ต่อไปเรื่อยๆ ก่อนหน้า สำหรับกรณีข้างต้น การย้ายเพียง 5 ครั้ง เลยต้องเลื่อนซ้าย 1 (B) ไปตาม 5

1 <<../ 5 // 32

// Shift the bit by 5 spots
______
|    |
V    V
100001 = 100000 = 32

จากนั้นค่าดังกล่าวจะถูกแปลงจากค่าที่ลงชื่อของ VLQ โดยการเลื่อนตัวเลข (32) ไปทางขวาหนึ่งจุด

32 >> 1 // 16
//or
100000
|
 |
 V
010000 = 16

ก็เรียบร้อย แค่นี้คุณก็เปลี่ยน 1 เป็น 16 แล้ว นี่อาจดูเป็นขั้นตอนที่ยุ่งยากเกินไป แต่เมื่อตัวเลขต่างๆ เริ่มมีขนาดใหญ่ขึ้นก็จะเหมาะสมมากขึ้น

ปัญหา XSSI ที่อาจเกิดขึ้น

ข้อกำหนดดังกล่าวกล่าวถึงปัญหาการรวมสคริปต์ข้ามเว็บไซต์ที่อาจเกิดขึ้นจากการใช้การแมปแหล่งที่มา เพื่อลดปัญหานี้ ขอแนะนำให้คุณแทรกบรรทัดแรกของการแมปแหล่งที่มาด้วย ")]}" เพื่อยกเลิกการทำงานของ JavaScript โดยการจงใจทำให้เกิดข้อผิดพลาดทางไวยากรณ์ ซึ่งเครื่องมือสำหรับนักพัฒนา WebKit สามารถจัดการได้อยู่แล้ว

if (response.slice(0, 3) === ")]}") {
    response = response.substring(response.indexOf('\n'));
}

ดังที่แสดงด้านบน อักขระ 3 ตัวแรกจะถูกตัดออกเพื่อตรวจสอบว่าตรงกับข้อผิดพลาดทางไวยากรณ์ในข้อกำหนดหรือไม่ และหากเป็นเช่นนั้น จะเป็นการนำอักขระทั้งหมดที่นำไปสู่เอนทิตีบรรทัดใหม่ตัวแรกออก (\n)

การทํางานของ sourceURL และ displayName: Eval และฟังก์ชันแบบไม่ระบุชื่อ

แม้ว่าแผนที่แหล่งที่มาจะไม่ใช่ส่วนหนึ่งของการแมปแหล่งที่มา แต่ แต่รูปแบบ 2 ข้อต่อไปนี้จะช่วยให้คุณทำให้การพัฒนาง่ายขึ้นมากเมื่อใช้กับฟังก์ชัน EV และไม่ระบุตัวตน

ผู้ช่วยคนแรกดูคล้ายกับพร็อพเพอร์ตี้ //# sourceMappingURL มากและมีการกล่าวถึงในข้อกำหนดของแผนที่แหล่งที่มา V3 การใส่ความคิดเห็นพิเศษต่อไปนี้ในโค้ดของคุณ ซึ่งจะถูก การประเมิน คุณสามารถตั้งชื่อ evael ให้ปรากฏเป็นชื่อที่สมเหตุสมผลในเครื่องมือการพัฒนาของคุณ ดูตัวอย่างง่ายๆ โดยใช้คอมไพเลอร์ CoffeeScript:

สาธิต: ดูโค้ดของ eval() ที่แสดงเป็นสคริปต์ผ่าน URL ที่มา

//# sourceURL=sqrt.coffee

ผู้ช่วยอีกตัวหนึ่งจะให้คุณตั้งชื่อฟังก์ชันที่ไม่ระบุตัวตนโดยใช้พร็อพเพอร์ตี้ displayName ที่มีอยู่ในบริบทปัจจุบันของฟังก์ชันที่ไม่ระบุตัวตน ทำโปรไฟล์การสาธิตต่อไปนี้เพื่อดูการทำงานของพร็อพเพอร์ตี้ displayName

btns[0].addEventListener("click", function(e) {
    var fn = function() {
        console.log("You clicked button number: 1");
    };

    fn.displayName = "Anonymous function of button 1";

    return fn();
}, false);

เมื่อทำโปรไฟล์โค้ดภายในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ พร็อพเพอร์ตี้ displayName จะแสดงขึ้นแทนรายการอย่างเช่น (anonymous) แต่ displayName ค่อนข้างตายในน้ำและจะไม่อยู่ใน Chrome แต่ความหวังทั้งหมดไม่ได้หายไป เราแนะนำข้อเสนอที่ดีกว่าเดิมให้คุณที่ชื่อว่า debugName

ขณะที่เขียนการตั้งชื่อ eval จะใช้ได้เฉพาะในเบราว์เซอร์ Firefox และ WebKit เท่านั้น พร็อพเพอร์ตี้ displayName อยู่ใน WebKit ต่อคืนเท่านั้น

มารวมตัวกัน

ขณะนี้มีการพูดคุยที่ใช้เวลานานมากเกี่ยวกับการสนับสนุนการแมปแหล่งที่มาซึ่งเพิ่มลงใน CoffeeScript ตรวจสอบปัญหานี้และเพิ่มการสนับสนุนของคุณสำหรับการสร้างการแมปแหล่งที่มาลงในคอมไพเลอร์ CoffeeScript นี่จะเป็นชัยชนะครั้งใหญ่สำหรับ CoffeeScript และผู้ติดตามที่ทุ่มเท

UglifyJS ยังมีปัญหาการแมปแหล่งที่มาที่คุณควรตรวจสอบด้วยเช่นกัน

มีtoolsจำนวนมากที่ใช้สร้างแผนที่ต้นฉบับ รวมถึงคอมไพเลอร์ Coffeescript ผมถือว่านี่เป็นประเด็นหลักในขณะนี้

ยิ่งเรามีเครื่องมือที่สามารถสร้างแผนที่แหล่งที่มาได้มากเท่าไร เราก็จะยิ่งเก่งขึ้นมากเท่านั้น ขอให้คุณถามหรือเพิ่มการสนับสนุนแผนที่แหล่งที่มาให้กับโครงการโอเพนซอร์สที่คุณชื่นชอบ

ยังไม่สมบูรณ์แบบ

สิ่งหนึ่งที่แผนที่แหล่งที่มายังใช้งานไม่ได้ในตอนนี้คือนิพจน์การดู ปัญหาคือการพยายามตรวจสอบอาร์กิวเมนต์หรือชื่อตัวแปรภายในบริบทการดำเนินการปัจจุบัน ผลลัพธ์ที่ได้จะไม่มีอยู่จริง ซึ่งจำเป็นต้องใช้การแมปแบบย้อนกลับบางอย่างเพื่อค้นหาชื่อจริงของอาร์กิวเมนต์/ตัวแปรที่คุณต้องการตรวจสอบ โดยเทียบกับชื่ออาร์กิวเมนต์/ตัวแปรจริงใน JavaScript ที่คอมไพล์ของคุณ

แน่นอนว่านี่เป็นปัญหาที่สามารถแก้ไขได้ และเมื่อให้ความสนใจกับแผนที่แหล่งที่มามากขึ้น เราก็จะเริ่มเห็นคุณลักษณะที่น่าทึ่งบางอย่างและความเสถียรที่ดีขึ้น

ปัญหา

เมื่อเร็วๆ นี้ jQuery 1.9 ได้เพิ่มการรองรับแผนที่แหล่งที่มาเมื่อแสดงผลนอก CDN อย่างเป็นทางการ และยังชี้ให้เห็นข้อบกพร่องที่ผิดปกติเมื่อมีการใช้ความคิดเห็นการคอมไพล์แบบมีเงื่อนไขของ IE (//@cc_on) ก่อนโหลด jQuery ด้วย นับแต่นั้นมาได้มีการคอมมิตเพื่อลดปัญหานี้โดยการรวม sourceMappingURL ไว้ในความคิดเห็นแบบหลายบรรทัด บทเรียนที่ต้องเรียนรู้ไม่ใช้ความคิดเห็นแบบมีเงื่อนไข

ซึ่งได้รับการแก้ไขแล้วโดยเปลี่ยนไวยากรณ์เป็น //# แล้ว

เครื่องมือและแหล่งข้อมูล

ต่อไปนี้เป็นแหล่งข้อมูลและเครื่องมือเพิ่มเติมที่คุณควรลองใช้

• Nick Fitzgerald มีส้อม UglifyJS พร้อมการรองรับการแมปแหล่งที่มา
• Paul Ireland มีการสาธิตเล็กๆ น้อยๆ ที่มีประโยชน์ซึ่งแสดงแผนที่แหล่งที่มา
• ลองดูชุดเปลี่ยน WebKit เพื่อดูว่าเมื่อใดที่ลดลง
• ชุดการเปลี่ยนแปลงยังมีการทดสอบเลย์เอาต์ซึ่งเป็นการเริ่มต้นของบทความทั้งหมด
• Mozilla มีข้อบกพร่องที่คุณควรปฏิบัติตามเกี่ยวกับสถานะของแผนที่แหล่งที่มาในคอนโซลในตัว
• Conrad Irwin ได้เขียนแหล่งข้อมูลแผนที่แหล่งที่มาที่มีประโยชน์อย่างยิ่งสำหรับผู้ใช้ Ruby ทุกคน
• อ่านเพิ่มเติมเกี่ยวกับการตั้งชื่อการประเมินและพร็อพเพอร์ตี้ displayName
• คุณดูแหล่งที่มาของคอมไพเลอร์การปิดเพื่อสร้างการแมปแหล่งที่มาได้
• มีภาพหน้าจอและการพูดคุยเกี่ยวกับการรองรับแผนที่แหล่งที่มาของ GWT

แผนที่แหล่งที่มาเป็นยูทิลิตีที่ทรงประสิทธิภาพมากในชุดเครื่องมือของนักพัฒนา การทำให้เว็บแอปมีขนาดเล็กแต่แก้ไขข้อบกพร่องได้ง่ายจะเป็นประโยชน์อย่างยิ่ง และยังเป็นเครื่องมือการเรียนรู้ที่มีประสิทธิภาพมากสำหรับนักพัฒนาซอฟต์แวร์รุ่นใหม่ คุณจะได้เห็นว่านักพัฒนาซอฟต์แวร์ที่มีประสบการณ์วางโครงสร้างอย่างไร และเขียนแอปได้โดยไม่ต้องลุยกับโค้ดที่ลดขนาดที่อ่านไม่ได้

อย่ามัวรอช้า เริ่มสร้างการแมปแหล่งที่มาสำหรับทุกโปรเจ็กต์เลย