คุณเคยคิดอยากอัปเดตโค้ดฝั่งไคลเอ็นต์ให้อ่านง่ายและแก้ไขข้อบกพร่องที่สำคัญกว่าได้หลังจากผสานรวมและลดขนาดโค้ดแล้ว โดยไม่ส่งผลต่อประสิทธิภาพ ตอนนี้คุณสามารถสัมผัสความมหัศจรรย์ของแผนที่แหล่งที่มาได้แล้ว
การแมปแหล่งที่มาเป็นวิธีการแมปไฟล์ที่รวม/ลดขนาดกลับไปยังสถานะที่ไม่ได้สร้าง เมื่อคุณสร้างแผนที่สำหรับเวอร์ชันที่ใช้งานจริง ตลอดจนการลดขนาดและการรวมไฟล์ JavaScript คุณจะสร้างแผนที่แหล่งที่มาซึ่งมีข้อมูลเกี่ยวกับไฟล์ต้นฉบับ เมื่อคุณค้นหาหมายเลขบรรทัดและหมายเลขคอลัมน์ใน JavaScript ที่สร้างขึ้น คุณจะทำการค้นหาในแผนที่แหล่งที่มาซึ่งจะแสดงตำแหน่งเดิมได้ เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ (ขณะนี้คือ WebKit รุ่น Nightly, Google Chrome หรือ Firefox 23 ขึ้นไป) สามารถแยกวิเคราะห์แผนที่แหล่งที่มาโดยอัตโนมัติและทำให้ดูเหมือนว่าคุณกำลังเรียกใช้ไฟล์ที่ยังไม่ได้ย่อและไม่ได้อยู่รวมกัน
การสาธิตช่วยให้คุณคลิกขวาที่ใดก็ได้ในพื้นที่ข้อความที่มีแหล่งที่มาที่สร้างขึ้น เลือก "รับตำแหน่งเดิม" จะค้นหาการแมปแหล่งที่มาโดยการส่งหมายเลขบรรทัดและคอลัมน์ที่สร้างขึ้น และแสดงผลตำแหน่งในโค้ดเดิม ตรวจสอบว่าคอนโซลเปิดอยู่เพื่อให้มองเห็นผลลัพธ์
![ตัวอย่างไลบรารีการแมปแหล่งที่มา Mozilla JavaScript ในสถานการณ์จริง](https://developer.chrome.com/static/blog/sourcemaps/image/example-the-mozilla-java-39006f2bd61b7.png?authuser=19&hl=th)
โลกแห่งความเป็นจริง
ก่อนที่คุณจะดูการใช้งานแผนที่แหล่งที่มาในชีวิตจริงต่อไปนี้ โปรดเปิดใช้งานฟีเจอร์แผนที่แหล่งที่มาใน Chrome Canary หรือ WebKit ตอนกลางคืนโดยคลิกเฟืองการตั้งค่าในแผงเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ แล้วทำเครื่องหมายที่ "เปิดใช้แผนที่แหล่งที่มา" ตัวเลือก
![วิธีเปิดใช้การแมปแหล่งที่มาในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ WebKit](https://developer.chrome.com/static/blog/sourcemaps/image/how-enable-source-maps-f4e0c38283a6b.png?authuser=19&hl=th)
Firefox 23+ ได้เปิดใช้แผนที่ที่มาโดยค่าเริ่มต้นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ภายใน
![วิธีเปิดใช้งานการแมปแหล่งที่มาในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Firefox](https://developer.chrome.com/static/blog/sourcemaps/image/how-enable-source-maps-f340306c71741.png?authuser=19&hl=th)
เหตุใดฉันจึงควรสนใจการแมปแหล่งที่มา
ตอนนี้การแมปแหล่งที่มาจะทำงานระหว่าง 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 ที่เทียบเท่า
![การแก้ไขข้อบกพร่องของ Traceur ES6 โดยใช้การแมปแหล่งที่มา](https://developer.chrome.com/static/blog/sourcemaps/image/traceur-es6-debugging-usi-009b84ddde462.png?authuser=19&hl=th)
การสาธิต: เขียน ES6, แก้ไขข้อบกพร่อง และดูการทำงานของการแมปแหล่งที่มา
การแมปแหล่งที่มาทำงานอย่างไร
คอมไพเลอร์/ตัวแทรก JavaScript เพียงตัวเดียวที่รองรับสำหรับการสร้างการแมปแหล่งที่มาในขณะนี้คือคอมไพเลอร์ Closure (เราจะอธิบายวิธีใช้ในภายหลัง) เมื่อคุณได้รวมและลดขนาด JavaScript แล้ว JavaScript นั้นจะมีไฟล์การแมปแหล่งที่มาอยู่
ปัจจุบัน คอมไพเลอร์ Closure ไม่ได้ใส่ข้อคิดเห็นพิเศษในตอนท้ายซึ่งจำเป็นเพื่อแสดงถึงเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ที่มีแผนที่แหล่งที่มา
//# sourceMappingURL=/path/to/file.js.map
ซึ่งจะทำให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์จับคู่การโทรกลับไปยังตำแหน่งของตนในไฟล์ต้นทางได้ ก่อนหน้านี้ เครื่องมือแสดงความคิดเห็นคือ //@
แต่เนื่องจากปัญหาบางอย่างเกี่ยวกับความคิดเห็นดังกล่าวและความคิดเห็นของ IE เกี่ยวกับการรวบรวมแบบมีเงื่อนไขทำให้มีการตัดสินใจในการเปลี่ยนเป็น //#
ปัจจุบันมี Chrome Canary, WebKit Nightly และ Firefox 24 ขึ้นไปรองรับโปรแกรมแก้ไขความคิดเห็นใหม่ การเปลี่ยนแปลงไวยากรณ์นี้จะส่งผลต่อ sourceURL ด้วย
หากคุณไม่ชอบความคิดเห็นแปลกๆ คุณสามารถตั้งค่าส่วนหัวพิเศษในไฟล์ JavaScript ที่คอมไพล์ได้ โดยทำดังนี้
X-SourceMap: /path/to/file.js.map
เช่นเดียวกับความคิดเห็น วิธีนี้จะช่วยให้ผู้บริโภคแผนที่ต้นทางมองหาการแมปแหล่งที่มาที่เชื่อมโยงกับไฟล์ JavaScript ได้ที่ใด ส่วนหัวนี้ยังช่วยแก้ปัญหาการอ้างอิงแผนที่แหล่งที่มาในภาษาที่ไม่รองรับความคิดเห็นบรรทัดเดียวด้วย
![ตัวอย่าง WebKit Devtools ของการแมปแหล่งที่มาในและปิดการแมปแหล่งที่มา](https://developer.chrome.com/static/blog/sourcemaps/image/webkit-devtools-example-c12bbff458a3c.png?authuser=19&hl=th)
ระบบจะดาวน์โหลดไฟล์การแมปแหล่งที่มาก็ต่อเมื่อคุณเปิดใช้การแมปแหล่งที่มาและเปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ไว้ นอกจากนี้ คุณจะต้องอัปโหลดไฟล์ต้นฉบับเพื่อให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์อ้างอิงและแสดงไฟล์ดังกล่าวได้เมื่อจำเป็น
ฉันจะสร้างแผนที่แหล่งที่มาได้อย่างไร
คุณจะต้องใช้คอมไพเลอร์การปิดเพื่อลดขนาด เชื่อมต่อ และสร้างการแมปแหล่งที่มาสำหรับไฟล์ 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
ซึ่งจำเป็นเนื่องจากเวอร์ชันเริ่มต้นคือ V2 และเราต้องการใช้งานกับ V3 เท่านั้น
โครงสร้างของแผนที่แหล่งที่มา
เพื่อให้เข้าใจการแมปแหล่งที่มาได้ดียิ่งขึ้น เราจะยกตัวอย่างเล็กๆ ของไฟล์การแมปแหล่งที่มาที่คอมไพเลอร์ 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% ดังนั้นสำหรับไฟล์ 133kB คุณจะได้รับแผนที่ต้นฉบับประมาณ 300 kB
แล้วพวกเขาลดขนาดอย่างไรในขณะที่ยังคงรักษาการแมปที่ซับซ้อนไว้ได้
VLQ (Variable Length Quantity) จะใช้ร่วมกับการเข้ารหัสค่าเป็นค่า Base64 พร็อพเพอร์ตี้การแมปเป็นสตริงขนาดใหญ่มาก ภายในสตริงนี้มีเครื่องหมายเซมิโคลอน (;) ซึ่งแสดงหมายเลขบรรทัดภายในไฟล์ที่สร้างขึ้น ภายในแต่ละบรรทัดจะมีเครื่องหมายจุลภาค (,) ซึ่งแสดงแต่ละส่วนภายในบรรทัดนั้น แต่ละกลุ่มคือ 1, 4 หรือ 5 ในช่องความยาวตัวแปร บางลิงก์อาจยาวกว่านี้ แต่จะมีบิตต่อเนื่อง แต่ละกลุ่มสร้างขึ้นจากส่วนก่อนหน้า ซึ่งช่วยลดขนาดของไฟล์เนื่องจากแต่ละบิตจะสัมพันธ์กับส่วนก่อนหน้า
![รายละเอียดกลุ่มภายในไฟล์ JSON ของการแมปแหล่งที่มา](https://developer.chrome.com/static/blog/sourcemaps/image/breakdown-a-segment-with-118944cecc633.png?authuser=19&hl=th)
ดังที่กล่าวไว้ข้างต้น แต่ละส่วนจะมีความยาวตัวแปรได้เป็น 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) ไปทางขวา 1 จุด
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 แบบต่อไปนี้จะไม่ได้เป็นส่วนหนึ่งของข้อกำหนดของแผนที่แหล่งที่มา แต่จะช่วยให้คุณพัฒนาได้ง่ายขึ้นมากเมื่อทำงานกับ Eval และฟังก์ชันที่ไม่ระบุตัวตน
ตัวช่วยแรกดูคล้ายกับพร็อพเพอร์ตี้ //# sourceMappingURL
มากและจริงๆ แล้วมีการกล่าวถึงในข้อกำหนดของการแมปแหล่งที่มา V3 คุณตั้งชื่อการประเมินเพื่อให้ปรากฏเป็นชื่อเชิงตรรกะมากขึ้นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ ด้วยการใส่ความคิดเห็นพิเศษต่อไปนี้ในโค้ดของคุณ ดูการสาธิตง่ายๆ ที่ใช้คอมไพเลอร์ CoffeeScript:
การสาธิต: ดูการแสดงโค้ดของ eval()
เป็นสคริปต์ผ่าน sourceURL
//# sourceURL=sqrt.coffee
![ความคิดเห็นพิเศษของ sourceURL มีลักษณะอย่างไรในเครื่องมือสำหรับนักพัฒนา](https://developer.chrome.com/static/blog/sourcemaps/image/what-sourceurl-special-co-22d70f6e53736.png?authuser=19&hl=th)
ผู้ช่วยอีกตัวช่วยให้คุณตั้งชื่อฟังก์ชันที่ไม่ระบุชื่อโดยใช้พร็อพเพอร์ตี้ 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](https://developer.chrome.com/static/blog/sourcemaps/image/showing-displayname-prop-6b79ae56ea472.png?authuser=19&hl=th)
เมื่อทำการสร้างโปรไฟล์โค้ดภายในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ พร็อพเพอร์ตี้ displayName
จะแสดงขึ้นแทนที่จะเป็นรูปแบบ (anonymous)
อย่างไรก็ตาม displayName นั้นจมอยู่ในน้ำแล้ว และจะไม่มีการนำเข้ามาไว้ใน Chrome แต่ความหวังก็ไม่ได้หายไป และมีการเสนอข้อเสนอที่ดีกว่าเดิมมากว่า debugName
เมื่อเขียนชื่อการประเมินแล้วจะใช้ได้กับเบราว์เซอร์ Firefox และ WebKit เท่านั้น พร็อพเพอร์ตี้ displayName
มีอยู่ใน WebKit เท่านั้น
มารวมตัวกัน
ขณะนี้มีการพูดคุยกันอย่างยาวมากเกี่ยวกับการสนับสนุนแผนที่ต้นทางที่เพิ่มลงใน CoffeeScript ตรวจสอบปัญหาและเพิ่มการสนับสนุนสำหรับการเพิ่มการสร้างแผนที่ต้นทางลงในคอมไพเลอร์ CoffeeScript นี่จะเป็นความสำเร็จครั้งใหญ่สำหรับ CoffeeScript และผู้ติดตามที่อุทิศตน
UglifyJS ยังมีปัญหาเกี่ยวกับแผนที่ต้นทางที่คุณควรตรวจสอบด้วยเช่นกัน
เครื่องมือจำนวนมากสำหรับสร้างแผนที่แหล่งที่มา รวมถึงคอมไพเลอร์ Coffeescript ฉันถือว่านี่เป็นประเด็นหลักตอนนี้
ยิ่งเรามีเครื่องมือที่สามารถสร้างการแมปแหล่งที่มาได้มากเท่าไร เราก็จะยิ่งทำได้ดียิ่งขึ้นเท่านั้น ดังนั้น ถามหรือเพิ่มการสนับสนุนแผนที่แหล่งที่มาให้กับโปรเจ็กต์โอเพนซอร์สที่คุณชื่นชอบ
ยังไม่สมบูรณ์แบบ
สิ่งหนึ่งที่การแมปแหล่งที่มาใช้ไม่ได้กับตอนนี้คือการแสดงนิพจน์การดู ปัญหาคือการพยายามตรวจสอบชื่ออาร์กิวเมนต์หรือชื่อตัวแปรภายในบริบทการดำเนินการปัจจุบันจะไม่แสดงผลลัพธ์เนื่องจากไม่มีอยู่จริง ซึ่งจำเป็นต้องใช้การแมปแบบย้อนกลับเพื่อค้นหาชื่อจริงของอาร์กิวเมนต์/ตัวแปรที่คุณต้องการตรวจสอบ เมื่อเทียบกับชื่ออาร์กิวเมนต์/ตัวแปรจริงใน JavaScript ที่คอมไพล์
แน่นอนว่านี่เป็นปัญหาที่แก้ไขได้และเมื่อมีความสนใจมากขึ้นเกี่ยวกับการแมปแหล่งที่มา เราเริ่มเห็นคุณลักษณะที่น่าทึ่งบางอย่างและมีความเสถียรที่ดีขึ้น
ปัญหา
เมื่อเร็วๆ นี้ jQuery 1.9 ได้เพิ่มการรองรับการแมปแหล่งที่มาเมื่อแสดงผลนอก CDN อย่างเป็นทางการ และยังชี้ข้อบกพร่องที่แปลกไปเมื่อมีการใช้ความคิดเห็นคอมไพล์แบบมีเงื่อนไขของ IE (//@cc_on) ก่อนโหลด jQuery อีกด้วย ต่อมาได้มีการคอมมิตเพื่อลดปัญหานี้โดยการรวม sourceMappingURL ไว้ในความคิดเห็นแบบหลายบรรทัด บทเรียนที่ควรศึกษาไม่ใช้ความคิดเห็นแบบมีเงื่อนไข
จากนี้ได้รับการแก้ไขแล้วโดยเปลี่ยนไวยากรณ์เป็น //#
เครื่องมือและแหล่งข้อมูล
แหล่งข้อมูลและเครื่องมือเพิ่มเติมที่คุณควรพิจารณามีดังนี้
- Nick Fitzgerald แยก UglifyJS ที่รองรับการแมปแหล่งที่มาแล้ว
- Paul Ireland มีการสาธิตเล็กๆ น้อยๆ ที่น่าสนใจซึ่งแสดงแผนที่แหล่งข้อมูล
- ตรวจสอบชุดการเปลี่ยนแปลง WebKit ของเวลาที่ยกเลิก
- ชุดการเปลี่ยนแปลงยังมีการทดสอบเลย์เอาต์ซึ่งทำให้บทความทั้งหมดเริ่มต้นขึ้นด้วย
- Mozilla มีข้อบกพร่องที่คุณควรติดตามเกี่ยวกับสถานะของการแมปแหล่งที่มาในคอนโซลในตัว
- Conrad Irwin ได้เขียนอัญมณีแผนที่แหล่งที่มาที่มีประโยชน์อย่างมากสำหรับผู้ใช้ Ruby ทุกคน
- อ่านเพิ่มเติมเกี่ยวกับ eval Hostname และพร็อพเพอร์ตี้ displayName
- คุณสามารถดูแหล่งที่มาของคอมไพเลอร์การปิดสำหรับการสร้างการแมปแหล่งที่มาได้
- มีภาพหน้าจอและการพูดถึงการรองรับการแมปแหล่งที่มา GWT
การแมปแหล่งที่มาเป็นยูทิลิตีที่ทรงประสิทธิภาพในชุดเครื่องมือของนักพัฒนาซอฟต์แวร์ การทำให้เว็บแอปของคุณเป็นระเบียบแต่แก้ไขข้อบกพร่องได้ง่ายนั้นเป็นประโยชน์มาก และยังเป็นเครื่องมือการเรียนรู้ที่มีประสิทธิภาพมากสำหรับนักพัฒนาซอฟต์แวร์หน้าใหม่ในการดูว่านักพัฒนาซอฟต์แวร์มากประสบการณ์ใช้โครงสร้างและเขียนแอปอย่างไร โดยไม่ต้องเดินผ่านโค้ดที่ลดขนาดให้อ่านไม่ได้
อย่ามัวรอช้า เริ่มสร้างแผนที่แหล่งที่มาสำหรับทุกโปรเจ็กต์เลย