รีเฟรชสถาปัตยกรรมเครื่องมือสำหรับนักพัฒนาเว็บ: การย้ายข้อมูลเครื่องมือสำหรับนักพัฒนาเว็บไปยัง TypeScript

Tim van der Lippe
Tim van der Lippe
X GitHub

โพสต์นี้เป็นส่วนหนึ่งของชุดบล็อกโพสต์ที่อธิบายการเปลี่ยนแปลงที่เราทำกับสถาปัตยกรรมของเครื่องมือสำหรับนักพัฒนาเว็บและวิธีสร้าง

จากบทความเรื่องการย้ายข้อมูลไปยังโมดูล JavaScript และการย้ายข้อมูลไปยัง Web Components วันนี้เราจะมาต่อเรื่องซีรีส์บล็อกโพสต์เกี่ยวกับการเปลี่ยนแปลงที่เราทำกับสถาปัตยกรรมของ Devtools และวิธีสร้าง (หากยังไม่ได้ดู เราได้โพสต์วิดีโอเกี่ยวกับการอัปเกรดสถาปัตยกรรมของเครื่องมือสำหรับนักพัฒนาเว็บเป็นเว็บสมัยใหม่พร้อมเคล็ดลับ 14 ข้อเกี่ยวกับวิธีปรับปรุงโปรเจ็กต์เว็บ)

ในโพสต์นี้ เราจะอธิบายเส้นทาง 13 เดือนของเราในการเลิกใช้เครื่องมือตรวจสอบประเภทของ Closure Compiler ไปใช้ TypeScript

บทนำ

การใช้เครื่องมือตรวจสอบประเภทเป็นสิ่งจําเป็นเนื่องจากขนาดของโค้ดเบส DevTools และความต้องการสร้างความมั่นใจให้กับวิศวกรที่ทํางานกับโค้ดดังกล่าว ด้วยเหตุนี้ เครื่องมือสำหรับนักพัฒนาเว็บจึงใช้ Closure Compiler มาตั้งแต่ปี 2013 การใช้ Closure ช่วยให้วิศวกรเครื่องมือสำหรับนักพัฒนาเว็บทําการเปลี่ยนแปลงได้อย่างมั่นใจ เนื่องจากคอมไพเลอร์ Closure จะทําการตรวจสอบประเภทเพื่อให้แน่ใจว่าการผสานรวมระบบทั้งหมดได้รับการจัดประเภทอย่างถูกต้อง

อย่างไรก็ตาม เมื่อเวลาผ่านไป เครื่องมือตรวจสอบประเภทอื่นๆ ก็ได้รับความนิยมในเว็บพัฒนาสมัยใหม่ ตัวอย่างที่เห็นได้ชัด 2 ตัวอย่าง ได้แก่ TypeScript และ Flow นอกจากนี้ TypeScript ยังกลายเป็นภาษาโปรแกรมอย่างเป็นทางการของ Google แม้ว่าเครื่องมือตรวจสอบประเภทแบบใหม่เหล่านี้จะได้รับความนิยมมากขึ้น แต่เราก็สังเกตเห็นว่าเรากำลังเผยแพร่การถดถอยที่เครื่องมือตรวจสอบประเภทควรตรวจพบ เราจึงตัดสินใจประเมินตัวเลือกเครื่องมือตรวจสอบประเภทอีกครั้งและหาขั้นตอนถัดไปสำหรับการพัฒนาใน DevTools

การประเมินโปรแกรมตรวจสอบประเภท

เนื่องจากเครื่องมือสำหรับนักพัฒนาเว็บใช้โปรแกรมตรวจสอบประเภทอยู่แล้ว คำถามที่เราต้องการตอบคือ

เราจะใช้ Closure Compiler ต่อไปหรือเปลี่ยนไปใช้เครื่องมือตรวจสอบประเภทแบบใหม่

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

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

ความถูกต้องของประเภทใน TypeScript

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

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

การประเมิน TypeScript

เครื่องมือสำหรับนักพัฒนาเว็บมีมานานกว่า 10 ปีแล้ว ซึ่งได้เติบโตขึ้นเป็นเว็บแอปพลิเคชันขนาดใหญ่ที่เต็มไปด้วยฟีเจอร์ ขณะเขียนบล็อกโพสต์นี้ เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์มีโค้ด JavaScript ของบุคคลที่หนึ่งประมาณ 150,000 บรรทัด เมื่อเราเรียกใช้คอมไพเลอร์ TypeScript ในซอร์สโค้ด ปริมาณข้อผิดพลาดที่พบนั้นล้นหลาม เราพบว่าแม้ว่าคอมไพเลอร์ TypeScript จะแสดงข้อผิดพลาดที่เกี่ยวข้องกับการแก้ไขโค้ดน้อยลง (ข้อผิดพลาดประมาณ 2,000 ข้อ) แต่ยังคงมีข้อผิดพลาดอีก 6,000 ข้อในโค้ดเบสของเราที่เกี่ยวข้องกับความเข้ากันได้ของประเภท

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

สิ่งที่สำคัญอย่างหนึ่งเกี่ยวกับเรื่องนี้คือการใช้คอมไพเลอร์ Closure ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์มีการใช้ @unrestricted บ่อยครั้ง การกำกับเนื้อหาของคลาสด้วย @unrestricted จะปิดการตรวจสอบพร็อพเพอร์ตี้อย่างเข้มงวดของคอมไพเลอร์ Closure สำหรับคลาสนั้นๆ ซึ่งหมายความว่านักพัฒนาซอฟต์แวร์จะเพิ่มการกําหนดคลาสได้ตามต้องการโดยไม่ต้องคำนึงถึงความปลอดภัยของประเภท เราไม่พบบริบทที่ผ่านมาว่าเหตุใดการใช้ @unrestricted จึงแพร่หลายในโค้ดเบสของเครื่องมือสำหรับนักพัฒนาเว็บ แต่การใช้ดังกล่าวส่งผลให้คอมไพเลอร์ Closure ทำงานในโหมดที่ปลอดภัยน้อยกว่าสําหรับโค้ดเบสส่วนใหญ่

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

การโทร any

ณ จุดนี้ เราจึงต้องตัดสินใจว่าจะปรับปรุงการใช้งาน Closure Compiler หรือเปลี่ยนไปใช้ TypeScript (เนื่องจาก Google หรือ Chromium ไม่รองรับ Flow เราจึงต้องละทิ้งตัวเลือกนี้) เราเลือกคอมไพเลอร์ TypeScript โดยอิงตามการสนทนาและคำแนะนำจากวิศวกร Google ที่ทำงานเกี่ยวกับเครื่องมือ JavaScript/TypeScript (เมื่อเร็วๆ นี้ เราได้เผยแพร่บล็อกโพสต์เกี่ยวกับการย้ายข้อมูล Puppeteer ไปยัง TypeScript ด้วย)

เหตุผลหลักในการใช้คอมไพเลอร์ TypeScript คือความถูกต้องของประเภทที่ดีขึ้น ส่วนข้อดีอื่นๆ ได้แก่ การสนับสนุนจากทีม TypeScript ภายใน Google และฟีเจอร์ของภาษา TypeScript เช่น interfaces (ซึ่งต่างจาก typedefs ใน JSDoc)

การเลือกคอมไพเลอร์ TypeScript หมายความว่าเราต้องลงทุนอย่างมากในโค้ดเบสของ DevTools และสถาปัตยกรรมภายใน เราจึงประเมินว่าต้องใช้เวลาอย่างน้อย 1 ปีในการย้ายข้อมูลไปยัง TypeScript (กำหนดไว้สำหรับไตรมาสที่ 3 ปี 2020)

การดำเนินการย้ายข้อมูล

คำถามที่ใหญ่ที่สุดที่ยังเหลืออยู่คือ เราจะย้ายข้อมูลไปยัง TypeScript ได้อย่างไร เรามีโค้ด 150,000 บรรทัด และย้ายข้อมูลทั้งหมดในครั้งเดียวไม่ได้ และยังทราบด้วยว่าการเรียกใช้ TypeScript ในโค้ดเบสจะพบข้อผิดพลาดหลายพันรายการ

เราประเมินตัวเลือกต่างๆ ดังนี้

  1. ดูข้อผิดพลาด TypeScript ทั้งหมดและเปรียบเทียบกับเอาต์พุต "Golden" แนวทางนี้จะคล้ายกับแนวทางของทีม TypeScript ข้อเสียที่ใหญ่ที่สุดของแนวทางนี้คือการเกิดข้อขัดแย้งในการผสานบ่อยครั้ง เนื่องจากมีวิศวกรหลายสิบคนทํางานในโค้ดเบสเดียวกัน
  2. ตั้งค่าประเภทที่มีปัญหาทั้งหมดเป็น any ซึ่งจะทำให้ TypeScript ระงับข้อผิดพลาด เราไม่ได้ใช้ตัวเลือกนี้เนื่องจากเป้าหมายในการย้ายข้อมูลคือความถูกต้องของประเภท ซึ่งการระงับจะบั่นทอน
  3. แก้ไขข้อผิดพลาด TypeScript ทั้งหมดด้วยตนเอง ซึ่งจะต้องแก้ไขข้อผิดพลาดหลายพันรายการ ซึ่งใช้เวลานาน

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

อย่างไรก็ตาม เราเชื่อว่าการใช้ TypeScript จะช่วยให้เราป้องกันปัญหาในอนาคตได้ โดยเฉพาะปัญหาเกี่ยวกับการถดถอย ด้วยเหตุนี้ อาร์กิวเมนต์จึงไม่ใช่ "เรากําลังเพิ่มมูลค่าทางธุรกิจใหม่" แต่กลับเป็น "เรากําลังรักษามูลค่าทางธุรกิจที่ได้ไว้"

การรองรับ JavaScript ของคอมไพเลอร์ TypeScript

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

เราทำงานแบบขนานได้ด้วยการเพิ่ม @ts-nocheck ลงในไฟล์ทุกไฟล์ใน DevTools ล่วงหน้า กระบวนการ "แก้ไข TypeScript" คือการนําคําอธิบายประกอบ @ts-nocheck ออกและแก้ไขข้อผิดพลาดที่ TypeScript จะพบ ซึ่งหมายความว่าเรามั่นใจว่าไฟล์แต่ละไฟล์ได้รับการตรวจสอบและแก้ไขปัญหาประเภทต่างๆ ให้ได้มากที่สุดแล้ว

โดยทั่วไปแล้ว แนวทางนี้ใช้ได้ผลโดยมีปัญหาน้อยมาก เราพบข้อบกพร่องหลายรายการในคอมไพเลอร์ TypeScript แต่ส่วนใหญ่นั้นไม่ชัดเจน

  1. ระบบจะถือว่าพารามิเตอร์ที่ไม่บังคับซึ่งมีประเภทฟังก์ชันที่แสดงผล any เป็นพารามิเตอร์ที่ต้องระบุ: #38551
  2. การกำหนดพร็อพเพอร์ตี้ให้กับเมธอดแบบคงที่ของคลาสทำให้การประกาศใช้งานไม่ได้ #38553
  3. การประกาศคลาสย่อยที่มีตัวสร้างที่ไม่มีอาร์กิวเมนต์และคลาสหลักที่มีตัวสร้างที่มีอาร์กิวเมนต์จะละเว้นตัวสร้างของคลาสย่อย: #41397

ข้อบกพร่องเหล่านี้แสดงให้เห็นว่าในกรณี 99% คอมไพเลอร์ TypeScript เป็นรากฐานที่มั่นคงสำหรับการต่อยอด ใช่ บางครั้งข้อบกพร่องที่คลุมเครือเหล่านี้อาจทำให้เกิดปัญหากับ DevTools แต่ส่วนใหญ่แล้วข้อบกพร่องเหล่านี้คลุมเครือมากพอที่เราจะสามารถแก้ปัญหาได้ง่ายๆ

ปัญหาเดียวที่ทำให้เกิดความสับสนคือเอาต์พุตที่ไม่แน่นอนของไฟล์ .tsbuildinfo: #37156 ที่ Chromium เรากำหนดว่าบิลด์ 2 รายการของ Chromium Commit เดียวกันต้องให้ผลลัพธ์เหมือนกันทุกประการ ขออภัย วิศวกรบิลด์ Chromium ของเราพบว่าเอาต์พุต .tsbuildinfo เป็นแบบไม่แน่นอน: crbug.com/1054494 วิธีแก้ปัญหานี้คือการแพตช์ไฟล์ .tsbuildinfo (ซึ่งโดยพื้นฐานแล้วมี JSON) และประมวลผลในภายหลังเพื่อให้ได้ผลลัพธ์ที่แน่นอน: https://crrev.com/c/2091448 โชคดีที่ทีม TypeScript แก้ปัญหาต้นทางได้และเราสามารถนำวิธีแก้ปัญหานี้ออกได้เร็วๆ นี้ ขอขอบคุณทีม TypeScript ที่รับรายงานข้อบกพร่องและแก้ไขปัญหาเหล่านี้อย่างรวดเร็ว

โดยรวมแล้ว เราพอใจกับความถูกต้อง (ประเภท) ของคอมไพเลอร์ TypeScript เราหวังว่า Devtools ซึ่งเป็นโปรเจ็กต์ JavaScript แบบโอเพนซอร์สขนาดใหญ่จะช่วยเสริมความแข็งแกร่งให้กับการรองรับ JavaScript ใน TypeScript

การวิเคราะห์ผลที่ตามมา

เราทําความคืบหน้าได้ดีในการแก้ไขข้อผิดพลาดประเภทเหล่านี้และค่อยๆ เพิ่มจํานวนโค้ดที่ TypeScript ตรวจสอบ อย่างไรก็ตาม ในเดือนสิงหาคม 2020 (9 เดือนหลังจากการย้ายข้อมูลนี้) เราได้ตรวจสอบและพบว่าเราจะไม่ทันกำหนดเวลาด้วยความเร็วปัจจุบัน วิศวกรของเราคนหนึ่งสร้างกราฟการวิเคราะห์เพื่อแสดงความคืบหน้าของ "การเปลี่ยนเป็น TypeScript" (ชื่อที่เราตั้งให้การเปลี่ยนนี้)

ความคืบหน้าของการย้ายข้อมูล TypeScript

ความคืบหน้าการย้ายข้อมูล TypeScript - ติดตามจำนวนบรรทัดโค้ดที่เหลือที่ต้องย้ายข้อมูล

ระยะเวลาโดยประมาณที่เราคาดว่าจะเหลือสายรอ 0 สายอยู่ระหว่างเดือนกรกฎาคมถึงธันวาคม 2021 ซึ่งเกือบ 1 ปีหลังจากกำหนดเวลา หลังจากได้พูดคุยกับฝ่ายบริหารและวิศวกรคนอื่นๆ แล้ว เราตกลงที่จะเพิ่มจำนวนวิศวกรที่ทำงานเกี่ยวกับการย้ายข้อมูลไปยังการรองรับคอมไพเลอร์ TypeScript ซึ่งเป็นไปได้เนื่องจากเราออกแบบการย้ายข้อมูลให้ทำงานแบบขนานได้ เพื่อให้วิศวกรหลายคนที่ทำงานกับไฟล์หลายไฟล์ไม่ทำงานขัดแย้งกัน

เมื่อถึงจุดนี้ กระบวนการเปลี่ยนเป็น TypeScript จึงกลายเป็นความพยายามของทั้งทีม ความช่วยเหลือเพิ่มเติมนี้ช่วยให้เราย้ายข้อมูลเสร็จสิ้นได้ภายในสิ้นเดือนพฤศจิกายน 2020 หรือ 13 เดือนหลังจากเริ่มต้น และนานกว่า 1 ปีก่อนการคาดการณ์ครั้งแรก

โดยรวมแล้วมีรายการการเปลี่ยนแปลง 771 รายการ (คล้ายกับคำขอดึงข้อมูล) ที่ส่งโดยวิศวกร 18 คน ข้อบกพร่องการติดตามของเรา (https://crbug.com/1011811) มีความคิดเห็นมากกว่า 1,200 รายการ (เกือบทั้งหมดเป็นโพสต์อัตโนมัติจากรายการการเปลี่ยนแปลง) ชีตการติดตามของเรามีแถวมากกว่า 500 แถวสำหรับไฟล์ทั้งหมดที่จะเปลี่ยนเป็น TypeScript ผู้ได้รับมอบหมาย และรายการการเปลี่ยนแปลงที่ "เปลี่ยนเป็น TypeScript"

การลดผลกระทบต่อประสิทธิภาพของคอมไพเลอร์ TypeScript

ปัญหาใหญ่ที่สุดที่เรากำลังเผชิญอยู่ในปัจจุบันคือประสิทธิภาพที่ช้าของคอมไพเลอร์ TypeScript ปัญหาคอขวดนี้ทำให้เกิดต้นทุนสูงเมื่อพิจารณาจากจำนวนวิศวกรที่พัฒนา Chromium และ DevTools ขออภัยที่เราไม่สามารถระบุความเสี่ยงนี้ก่อนที่จะย้ายข้อมูล และเราเพิ่งค้นพบเมื่อย้ายข้อมูลไฟล์ส่วนใหญ่ไปยัง TypeScript ว่าเวลาที่ใช้กับบิลด์ Chromium เพิ่มขึ้นอย่างเห็นได้ชัด https://crbug.com/1139220

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

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

สถานะปัจจุบันของ TypeScript ในเครื่องมือสำหรับนักพัฒนาเว็บ

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

ดาวน์โหลดแชแนลตัวอย่าง

ลองใช้ Chrome Canary, Dev หรือ เบต้า เป็นเบราว์เซอร์สำหรับนักพัฒนาซอฟต์แวร์เริ่มต้น ช่องทางเวอร์ชันตัวอย่างเหล่านี้จะช่วยให้คุณเข้าถึงฟีเจอร์ล่าสุดของ DevTools, ทดสอบ API ของแพลตฟอร์มเว็บที่ล้ำสมัย และช่วยค้นหาปัญหาในเว็บไซต์ของคุณก่อนที่ผู้ใช้จะพบ

ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

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