ทำไมควรรัน npm run type-check ก่อน commit และ deploy

การรัน npm run type-check คืออีกหนึ่งขั้นตอนสำคัญที่ช่วยตรวจสอบความถูกต้องของชนิดข้อมูลในโปรเจกต์ก่อนนำโค้ดไปรันจริง หลายคนมักรอให้ build พังก่อนแล้วค่อยย้อนกลับมาแก้ แต่ทีมที่ทำงานได้เร็วและเสถียรกว่ามักเพิ่มขั้นตอนนี้ไว้ตั้งแต่ก่อน commit

แม้บางครั้งแอปจะยังเปิดใช้งานได้ตามปกติ แต่ปัญหาเรื่อง type อาจซ่อนอยู่ลึกในระบบ การเช็กไว้ล่วงหน้าจึงช่วยลดความเสี่ยงและประหยัดเวลาได้มาก โดยเฉพาะเมื่อโปรเจกต์เริ่มใหญ่ขึ้น

npm run type-check คืออะไร

คำสั่งนี้เป็น script ที่กำหนดไว้ใน package.json โดยพฤติกรรมจริงจะขึ้นอยู่กับว่าทีมผูกคำสั่งไว้กับอะไร ตัวอย่างที่พบได้บ่อยคือ

"type-check": "tsc --noEmit"

ความหมายคือให้ TypeScript ตรวจสอบทั้งโปรเจกต์ แต่ไม่สร้างไฟล์ output ออกมา จึงเหมาะสำหรับใช้ตรวจ error อย่างเดียวโดยไม่กระทบขั้นตอน build

มันช่วยจับปัญหาอะไรได้บ้าง

การทำ type-check มีประโยชน์มากในการจับข้อผิดพลาดที่มองไม่เห็นจากการรันโปรแกรมทั่วไป เช่น

• ตัวแปรควรเป็น string แต่ส่ง number เข้าไป
• ฟังก์ชันต้องการ id ที่ห้ามเป็น undefined
• ใช้ object ไม่ครบ field ที่ระบบกำหนด
• เรียก property ที่ไม่มีอยู่จริง
• refactor โค้ดแล้ว type พังต่อเนื่องเป็นลูกโซ่

ตัวอย่างง่าย ๆ

function greet(name: string) {
  return "Hello " + name
}

greet(123)

โค้ดนี้อาจดูสั้นและเหมือนไม่น่ามีปัญหา แต่เมื่อรัน type-check ระบบจะฟ้องทันที เพราะ 123 ไม่ใช่ string

ทำไมควรรันก่อน commit หรือ deploy

การรัน type-check ตั้งแต่ต้นทางช่วยให้ทีมแก้ปัญหาได้เร็วกว่าเดิม เพราะความผิดพลาดถูกตรวจพบก่อนจะหลุดไปยังขั้นตอนถัดไป ข้อดีที่เห็นชัดมีดังนี้

• ลดโอกาสเกิดบั๊กใน production
• เพิ่มความมั่นใจเวลาทำ refactor
• ทำงานเป็นทีมได้ง่ายขึ้น เพราะ contract ของข้อมูลชัดเจน
• อ่านและดูแลโค้ดเก่าได้ง่ายขึ้น
• เหมาะมากกับโปรเจกต์ที่ขยายตัวเร็ว

หลายเฟรมเวิร์กไม่ได้ตรวจ type ครบทุกจุดระหว่างโหมดพัฒนาเสมอไป จึงมีกรณีที่หน้าเว็บยังเปิดได้ปกติ แต่ภายในโปรเจกต์มี type error ซ่อนอยู่ การแยกรัน type-check เป็นนิสัยจึงเป็นแนวทางที่ปลอดภัยกว่า

ใช้กับ JavaScript ได้ไหม

แม้โปรเจกต์จะยังไม่ใช้ TypeScript เต็มรูปแบบ ก็ยังนำแนวคิดนี้ไปใช้ได้ เช่น

• เปิดใช้ JSDoc type hint
• ค่อย ๆ migrate จาก JavaScript ไปเป็น TypeScript
• เริ่มจากบางโมดูลก่อน แล้วค่อยขยายทั้งโปรเจกต์

เมื่อระบบเริ่มรู้จักชนิดข้อมูลมากขึ้น ทีมก็จะเห็นประโยชน์ของ type-check ได้ทันที ทั้งในแง่ความชัดเจนของโค้ดและการลดข้อผิดพลาด

ควรวางไว้ตรงไหนใน workflow

ถ้าต้องการให้ workflow ลื่นและมีคุณภาพมากขึ้น ควรเพิ่ม npm run type-check เข้าไปในจุดสำคัญ เช่น

• รันก่อน push โค้ด
• ตั้งใน CI ให้ตรวจทุก pull request
• ใช้ร่วมกับ lint และ test

ลำดับที่ทีมมืออาชีพนิยมใช้บ่อยมีดังนี้

npm run lint
npm run type-check
npm test
npm run build

แต่ละคำสั่งทำหน้าที่ต่างกัน

• lint ตรวจเรื่อง style และความเสี่ยงบางรูปแบบ
• type-check ตรวจความถูกต้องของข้อมูล
• test ตรวจพฤติกรรมการทำงาน
• build ตรวจว่าเมื่อนำทุกอย่างมารวมกันแล้วระบบยังผ่านได้จริง

สิ่งที่หลายคนมักเข้าใจผิด

มีความเข้าใจผิดอยู่บ่อยครั้งว่า ถ้าโค้ดรันได้ก็แปลว่าถูกต้อง หรือถ้า test ผ่านก็แปลว่าปลอดภัยแล้ว แต่ในความเป็นจริง

• โค้ดรันได้ ไม่ได้แปลว่า type ถูก
• test ผ่าน ไม่ได้แปลว่าไม่มี type hole
• test ไม่ได้ครอบคลุมทุก input เสมอไป

ดังนั้น npm run type-check ไม่ได้มีไว้แทน test แต่เป็นอีกด่านสำคัญที่ช่วยกันบั๊กตั้งแต่ต้นทาง ก่อนที่ปัญหาจะลุกลามไปถึงผู้ใช้จริง

วิธีเริ่มต้นในโปรเจกต์

ถ้าในโปรเจกต์ยังไม่มี script นี้ สามารถเปิด package.json แล้วเพิ่มได้ทันที

"type-check": "tsc --noEmit"

แม้จะเป็นการเพิ่มเพียงเล็กน้อย แต่เมื่อโปรเจกต์ใหญ่ขึ้น จะช่วยประหยัดเวลาการไล่บั๊กและทำให้ทีมทำงานได้อย่างมั่นใจมากขึ้นอย่างชัดเจน

สรุป

npm run type-check เป็นเครื่องมือเล็ก ๆ ที่ให้ผลลัพธ์คุ้มค่ามาก โดยเฉพาะในโปรเจกต์ที่ใช้ TypeScript หรือกำลังวางระบบ type ให้ชัดเจนมากขึ้น มันช่วยจับข้อผิดพลาดก่อนเกิดปัญหาจริง ลดบั๊กใน production และทำให้การทำงานร่วมกันในทีมมีมาตรฐานขึ้น

ยิ่งโค้ดมีขนาดใหญ่และซับซ้อนมากเท่าไร ก็ยิ่งควรให้ระบบช่วยตรวจแทนคนมากขึ้น และ type-check คือหนึ่งในด่านที่ไม่ควรมองข้าม