TSConfig Generator: สร้าง tsconfig.json ระดับ production ได้ในไม่กี่วินาที

tsconfig.json คือไฟล์ที่ถูก copy กันมากที่สุดแต่ถูกเข้าใจน้อยที่สุดในสายงาน web development แทบทุกโปรเจกต์ TypeScript มีไฟล์นี้ แต่แทบไม่มีใครเขียนมันเองตั้งแต่ต้น และเกือบทุก repo มี option ตกทอดมาจาก blog บทไหนสักบท คำตอบใน forum หรือ scaffold รุ่นเก่ากว่า TypeScript ปัจจุบัน ผลลัพธ์คือ config แตกกันไปคนละทาง: strict เปิดครึ่ง ๆ, module กับ moduleResolution ขัดกันเอง หรือค่า JSX จากโปรเจกต์ Vue ถูกลอกมาไว้ในแอป Next.js

TSConfig Generator ตัดปัญหานั้นด้วยฟอร์มสั้น ๆ เลือก preset — Next.js, Vite, Node.js หรือ library — แล้วสลับ toggle สำหรับ strict flag, การจัดการ JSX, path alias, สไตล์ module resolution และ include/exclude glob เครื่องมือจะสร้าง tsconfig.json ที่สอดคล้องกันเองและพร้อมขึ้น production ตาม stack ที่คุณใช้จริง copy หรือ download ไปใช้ได้ทันที

ทุกอย่างทำงาน 100% ใน browser ไม่ต้องมี account ไม่ต้อง upload — ค่า config ของคุณไม่เคยออกจากเครื่องเลย

ทำไมต้องใช้ TSConfig Generator

• ค่าเริ่มต้นถูกต้องตาม environment — Next.js app, Vite bundle, บริการ Node.js และ library ที่เผยแพร่ ต้องการ compiler option ไม่เหมือนกัน preset จะเข้ารหัสความต่างเหล่านี้ไว้แทนการเดา
• strict flag เป็น toggle ชัดเจน — strict, noImplicitAny และ strictNullChecks ช่วยจับ bug จริง เครื่องมือทำให้มันเป็นทางเลือกที่มองเห็น ไม่ใช่ค่าที่ตกทอดมาโดยบังเอิญ
• ค่า module ตรงกับ bundler ของคุณ — คู่ module กับ moduleResolution คือจุดที่ config ที่เขียนมือพลาดบ่อยที่สุด เครื่องมือจะรักษาความสอดคล้องของคู่นี้ให้เอง
• path alias ที่ทำงานจริง — alias จะใช้ได้ก็ต่อเมื่อ baseUrl และ paths ตรงกับ resolver ของ bundler เครื่องมือจะสร้างทั้งคู่ให้พร้อมกัน
• glob แบบ include/exclude ที่อ่านออก — build output และ dependencies ไม่ควรเข้าสู่การ type check เครื่องมือครอบคลุมเฉพาะไฟล์ source ของคุณเท่านั้น
• เป็นส่วนตัวตั้งแต่การออกแบบ — เป็น client-side JavaScript ล้วน ปลอดภัยกับ codebase ที่ policy ห้ามส่งข้อมูลออกนอกเครื่อง

ฟีเจอร์หลัก

ผลลัพธ์น่าเชื่อถือเพราะ option จะปรากฏเฉพาะเมื่อมีความจำเป็น — โปรเจกต์ Node.js ล้วนจะไม่ได้ค่า jsx — และ option ที่เกี่ยวข้องกันจะขยับพร้อมกัน preset library จะพา declaration มาด้วย ส่วน preset ฝั่ง app คง noEmit เอาไว้เพราะ bundler เป็นเจ้าของงาน emit

วิธีใช้งาน

1. เปิด TSConfig Generator แล้วเลือก preset ให้ตรงกับโปรเจกต์: Next.js, Vite, Node.js หรือ library
2. สลับ strict toggle ที่ต้องการ เริ่มจากเปิดทั้งหมด แล้วค่อยผ่อนทีละตัวเมื่อมีเหตุผลจริง
3. เลือกการจัดการ JSX และสไตล์ module resolution ให้ตรงกับ framework และ bundler ของคุณ
4. เพิ่ม path alias ถ้าโปรเจกต์ใช้ แล้วปรับ include/exclude glob ให้ครอบคลุมไฟล์ source
5. ตรวจ tsconfig.json ที่ได้ copy หรือ download ลง repository root แล้วรัน type check ตามปกติ

Flag ที่เปลี่ยนทุกอย่าง

tsconfig.json ไม่ใช่การตั้งค่าเดี่ยว ๆ แต่คือกลุ่ม option หลายกลุ่ม แต่ละกลุ่มมีคำตอบผิดที่ทำให้อย่างอื่นพังเงียบ ๆ การรู้จักกลุ่มเหล่านี้เปลี่ยนไฟล์ที่ generate มาจากกล่องดำให้เป็นบันทึกการตัดสินใจ

ตระกูล strict — strict: true เป็น umbrella ที่เปิดเช็คหลายตัวพร้อมกัน รวม noImplicitAny และ strictNullChecks noImplicitAny ไม่ยอมให้ค่าใดตกไปอยู่ใน type any แบบผ่อนปรนเมื่อ compiler อนุมานไม่ได้ ทำให้ทุกที่ที่ลืมใส่ type ไม่กลายเป็นรูรั่วของ type safety strictNullChecks ทำให้ null และ undefined เป็น type ของตัวเองแทนที่จะ assign ได้กับทุกอย่าง ซึ่งลด runtime crash ได้มากที่สุดใน codebase TypeScript เปิด strict แล้วสองตัวนี้ติดมาเอง แต่การระบุแยกชัด ๆ ช่วยบันทึกเจตนาของทีมไว้

module กับ moduleResolution — module กำหนด syntax ของไฟล์ที่ emit ส่วน moduleResolution กำหนดวิธีที่ compiler ตามหาไฟล์ที่ import ชี้ไป bundler อย่าง Vite และ Next.js ต้องการ moduleResolution: "bundler" ซึ่งรองรับ exports map และ import แบบไม่ใส่นามสกุล ส่วน Node.js CommonJS แบบดั้งเดิมใช้ "node" (node10) หรือ "node16"/"nodenext" พร้อมค่า module ที่ตรงกัน ถ้าคู่นี้ไม่ตรงกันจะเจอ error cannot find module ที่ติดตั้ง package ใหม่กี่รอบก็ไม่หาย

ค่า JSX ตาม framework — jsx: "preserve" ปล่อย JSX ไว้ตามเดิมเพื่อให้ Next.js แปลงเองภายหลัง โปรเจกต์ React ที่ build ด้วย Vite มักใช้ "react-jsx" ซึ่ง inject import ของ runtime อัตโนมัติ ทำให้ไม่ต้องเขียน import React ใส่ค่าผิดจะโดนแปลงซ้ำสองรอบ หรือเหลือ JSX ดิบที่ควรเป็น JavaScript

path alias กับ bundler — ค่า paths อย่าง "@/*": ["./src/*"] สอน compiler ว่า @/components/Button หมายถึงอะไร แต่ bundler มี resolver ของตัวเองและไม่สน tsconfig paths เว้นแต่จะบอก Vite ต้องมี resolve.alias ที่ตรงกัน ส่วน Next.js อ่าน paths จาก tsconfig ให้เอง เครื่องมือสร้างฝั่ง TypeScript ให้ถูกต้องแล้ว เหลือแค่เติมบรรทัดเดียวฝั่ง bundler

include และ exclude — include ระบุว่าไฟล์ใดเข้าร่วม program ส่วน exclude ตัด node_modules และ build output ออก ใส่เยอะไป compiler จะเช็คไฟล์ที่ตายแล้วและช้าลง ใส่น้อยไป error จะหลบอยู่ในไฟล์ที่ editor ยังเปิดอยู่

ตัวอย่างผลลัพธ์พร้อมคำอธิบาย:

{
  "compilerOptions": {
    "target": "ES2022", // ระดับ syntax ที่ output รองรับ
    "module": "ESNext", // emit module syntax ยุคใหม่
    "moduleResolution": "bundler", // กติกาการหาไฟล์แบบ bundler
    "jsx": "preserve", // ปล่อย JSX ให้ framework จัดการ
    "strict": true, // เปิดตระกูลเช็คทั้งหมด
    "noImplicitAny": true, // ห้าม any แอบแฝง
    "strictNullChecks": true, // null เป็น type ของตัวเอง
    "paths": { "@/*": ["./src/*"] } // alias ต้อง mirror ฝั่ง bundler
  },
  "include": ["src", "next-env.d.ts"], // ไฟล์ที่เข้าร่วม program
  "exclude": ["node_modules"] // dependencies ไม่เข้ามา
}

ความต่างของแต่ละ preset — preset Next.js ปรับให้เข้ากับ framework: jsx: "preserve", resolution แบบ bundler และ glob ที่ครอบคลุม app routes กับ type definition preset Vite ถือว่า bundler เป็นคนแปลงและ minify การ type check จึงแยกจากการ emit preset Node.js ตรงเข้าหา runtime พร้อม resolution และ target ที่เหมาะกับฝั่ง server preset library คือกรณีพิเศษ เพราะเปิด declaration เพื่อให้ผู้ใช้ package ได้ type — ฝั่ง app ใช้ noEmit เพราะ bundler เป็นเจ้าของ output แต่ library ต้อง emit เอง

กรณีใช้งานจริง

เริ่มโปรเจกต์ใหม่

งาน greenfield คือจุดที่ config ที่ผิดฝังรากลึก การเลือก preset ตรงกับ stack ตั้งแต่นาทีที่ห้าทำให้ได้จุดเริ่มที่ป้องกันตัวได้ ไม่ใช่ไปพบหลายเดือนถัดมาว่า strict ไม่เคยเปิดจริงตั้งแต่แรก

รวม config ใน monorepo ให้เป็นชุดเดียว

monorepo มักสะสม tsconfig หนึ่งไฟล์ต่อหนึ่ง package และแต่ละไฟล์เลี้ยวไปคนละทาง generate config มาตรฐานหนึ่งชุดต่อ environment — app, service, library — แล้วใช้เป็นฐานร่วมที่ทุก package extends ต่อ ค่า module และ strict ก็จะไม่ต่างกันระหว่างเพื่อนบ้านอีก

migration codebase JavaScript เก่าแบบค่อยเป็นค่อยไป

เปลี่ยนนามสกุลเป็น .ts แล้วเปิดทุก flag พร้อมกัน ได้ error เป็นพันและงาน migration ที่ถูกทิ้งกลางทาง เริ่มจากปิด strict flag ก่อน ให้ program compile ผ่าน แล้วค่อย generate config เป้าหมายด้วยเครื่องมือและเปิด strict flag ทีละตัว

เขียน library สำหรับเผยแพร่

package ที่เผยแพร่ส่ง type ของตัวเองไปถึงผู้ใช้ทุกคน declaration และ glob ที่แม่นยำจึงไม่ใช่ทางเลือก preset library ให้รูปแบบนี้พอดี เก็บไฟล์ภายในออกจาก program และให้ entry point ของคุณมี type definition ที่สมบูรณ์

แนวปฏิบัติที่ดี

• เริ่ม strict แล้วอย่าผ่อน — เปิดครบตระกูลตั้งแต่วันแรก ปิดเช็คทีหลังง่าย แต่เพิ่มเข้าไปใน codebase ใหญ่คือโปรเจกต์หนึ่ง
• รักษา paths ให้ตรงกับ bundler — ทุก alias ใน paths ต้องมีค่าตรงกันใน resolve.alias ของ Vite หรือเทียบเท่าของ bundler คุณ ให้ถือว่าเป็นการแก้คู่เดียวกัน
• commit tsconfig.json — ไฟล์นี้คือส่วนหนึ่งของ build contract ไม่ใช่ preference ส่วนตัว เพื่อนร่วมทีมและ CI ควร type check ด้วยกฎชุดเดียวกัน
• อัปเกรด target อย่างมีแผน — เพิ่ม target และ module เมื่อ runtime ที่รองรับเปลี่ยน แล้วรัน test suite ให้ครบ
• ต่อยอด อย่าแตกสาขา — เติม compiler option แปลก ๆ ทับบนฐานที่ generate มาอย่างตั้งใจ แทนการเขียนใหม่ทั้งไฟล์

เริ่มสร้าง tsconfig.json ของคุณวันนี้

หนี้ config มองไม่เห็นจนถึงวันที่มันแอบกินบ่ายหนึ่งบ่ายของคุณไป เปิด TSConfig Generator เลือก preset สลับ strict flag แล้ว copy tsconfig.json ที่ถูกต้องสำหรับ stack ของคุณตั้งแต่ครั้งแรก ไม่ต้องมี account ไม่ต้อง upload ไม่มีอะไรต้องติดตั้ง

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• ESLint Config Generator — จับคู่ tsconfig กับ ESLint 9 flat config ยุคใหม่
• EditorConfig Generator — รักษา indentation และ line ending ให้ consistent ทุก editor
• OpenAPI to TypeScript Converter — แปลง API schema เป็น type ที่ tsconfig แบบ strict ของคุณบังคับใช้

ขอให้ compile ราบรื่น

คำถามที่พบบ่อย

ถ: เปิด strict: true แล้ว noImplicitAny กับ strictNullChecks ติดมาด้วยหรือไม่?

ตอบ: ใช่ umbrella ของ strict เปิดเช็คทั้งตระกูลรวมสองตัวนี้ด้วย เครื่องมือระบุแยกให้ชัดเพื่อให้คุณผ่อนตัวเดียวได้โดยไม่ต้องปิดทั้งตระกูล

ถ: path alias ใช้ได้ใน editor แต่พังตอน build ผิดที่ตรงไหน?

ตอบ: ฝั่ง TypeScript ถูกต้องแล้ว แต่ bundler มี resolver ของตัวเองที่ไม่สน tsconfig paths ต้องเพิ่ม alias ตรงกันใน resolve.alias ของ Vite หรือเทียบเท่า ยกเว้น Next.js ที่อ่าน paths จาก tsconfig ให้เอง

ถ: tsconfig ของ library ควร emit ไฟล์ ส่วน tsconfig ฝั่ง app ไม่ emit ใช่ไหม?

ตอบ: โดยทั่วไปใช่ app ปล่อยให้ bundler เป็นเจ้าของ output จึงคง noEmit เอาไว้ แต่ library ที่เผยแพร่ต้อง emit declaration file เอง preset library จึงเปิด declaration พร้อมค่าที่ปลอดภัยต่อการ emit