Node.js รองรับการรันไฟล์ TypeScript โดยไม่ต้องตั้งค่าเพิ่มเติม

 (nodejs.org)
21 คะแนน โดย GN⁺ 2025-08-18 | 7 ความคิดเห็น | แชร์ทาง WhatsApp
  • Node.js ได้รับการปรับปรุงให้สามารถ รันไฟล์ TypeScript ได้โดยตรง
  • ตอนนี้สามารถรันไฟล์ .ts ได้ทันทีโดยไม่ต้องมี การตั้งค่าเพิ่มเติม หรือการทรานส์ไพล์
  • นักพัฒนาสามารถเพิ่มประสิทธิภาพการทำงานได้โดยไม่ต้องใช้ tsconfig.json หรือติดตั้งบันเดลเลอร์แยกต่างหาก
  • ฟีเจอร์นี้ถูกรวมเข้าอย่างเป็นทางการตั้งแต่ Node.js เวอร์ชัน v22.18.0 (LTS)
  • คาดว่าจะช่วย ลดเส้นแบ่ง ระหว่างการพัฒนา JavaScript และ TypeScript

การรองรับการรัน TypeScript โดยตรงของ Node.js

  • เมื่อไม่นานมานี้ Node.js ได้เพิ่ม ความสามารถในการรันไฟล์ TypeScript (.ts) ได้โดยตรงในเวอร์ชัน v22.18.0 (LTS) โดยไม่ต้องพึ่งการตั้งค่าหรือเครื่องมือแยก
  • เดิมทีการรันโค้ด TypeScript ต้องใช้ ทรานส์ไพลเลอร์ภายนอก หรือ บันเดลเลอร์ เช่น ts-node, esbuild, Babel แต่ตอนนี้ Node.js สามารถรู้จำและรันโค้ด TypeScript ได้ด้วยตัวเองโดยไม่ต้องใช้เครื่องมือเหล่านั้น
  • ด้วยฟีเจอร์นี้ นักพัฒนาสามารถรันไฟล์ .ts บน Node.js ได้ทันทีโดยไม่ต้องมี ไฟล์ตั้งค่า tsconfig.json หรือไลบรารีเพิ่มเติม
  • ช่วยเพิ่ม ประสิทธิภาพการทำงาน และ ความสะดวกในการพัฒนา อย่างมากในงานอย่างการทำต้นแบบ การพัฒนาเชิงทดลอง และการรันสคริปต์
  • คาดว่าจะช่วยเสริม การเชื่อมโยงกัน ระหว่างโปรเจกต์ JavaScript และ TypeScript รวมถึงลดอุปสรรคในการเริ่มต้นสำหรับนักพัฒนาหน้าใหม่

การเปลี่ยนแปลงอื่นที่น่าสนใจ

  • esm: เพิ่มการใช้งาน import.meta.main
  • fs: ปรับปรุงการจัดการอีเวนต์ fs บนพื้นฐาน AsyncIterator
  • permission: รองรับการส่งต่อ permission model flag เมื่อรันซับโปรเซส
  • sqlite: เพิ่มตัวเลือก readBigInts
  • src/permission: รองรับ permission.has(addon)
  • url: เพิ่ม API fileURLToPathBuffer
  • watch: เพิ่มแฟลก --watch-kill-signal
  • worker: ปรับปรุงอ็อบเจ็กต์ Worker ให้เป็น async disposable

การอัปเดตด้านคอมมิตและเอกสาร

  • รวมถึงการลบโค้ดที่ไม่จำเป็น การจัดระเบียบสภาพแวดล้อมบิลด์และทูลเชน และการอัปเกรดเป็น npm 10.9.3
  • แก้ไขรายละเอียดตัวชี้วัดเสถียรภาพและหมายเลข RFC ในเอกสาร เช่น globals.md, child_process.md, http2
  • เพิ่มการทดสอบจำนวนมากและรวมการแก้ไขบั๊กไว้แล้ว

ไฟล์เผยแพร่

  • มีไฟล์ติดตั้งและไบนารีสำหรับ Windows, macOS(Intel/Apple Silicon), Linux(x64, ARM, PPC, s390x, AIX)
  • สามารถดาวน์โหลดซอร์สโค้ดและไฟล์รีลีสทั้งหมดได้จากหน้าดาวน์โหลดอย่างเป็นทางการของ Node.js
  • เอกสาร API ได้รับการอัปเดตตาม v22.18.0

บทความที่เกี่ยวข้อง

7 ความคิดเห็น

 
aliveornot 2025-08-19

โอ้ โล่งอกไปที... หวังว่ามันจะได้รับความนิยมอย่างรวดเร็ว
 
tested 2025-08-18

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

ยังต้องปรับนามสกุลไฟล์หรือพาธให้ตรงด้วยเพราะมีข้อผิดพลาดอย่าง ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT
และฟีเจอร์ที่ต้องอาศัยการรองรับการบิลด์ TypeScript ผ่านการตั้งค่า emitDecoratorMetadata อย่างเช่น NestJS ก็ใช้ไม่ได้ด้วย...
 
kimjeongwonn 2025-08-18

--experimental-strip-types ถูกเปิดใช้เป็นค่าเริ่มต้นเลยใช่ไหม?
 
click 2025-08-18

ยังไงผมก็ไม่ได้ใช้ enum อยู่แล้ว ดังนั้นสำหรับผม แค่ทำงานแบบลบ type ออกก็เพียงพอและรันได้ดีมากแล้ว
 
crawler 2025-08-18

สะดวกขึ้นมากเลยนะ!
 
honglu 2025-08-18

กลั้นความกดไลก์ไว้ไม่ไหวเลยครับ

เดิมก็คิดว่าแค่มีแฟลก --no-experimental-strip-types ก็ดีพอแล้ว

แต่ดูเหมือนว่าจะดียิ่งกว่านั้นอีกครับ
 
GN⁺ 2025-08-18
ความคิดเห็นใน Hacker News
  • ถ้าอยู่กับ node:test ใน Node.js ตอนนี้ผมคิดว่า Node.js แทบจะเป็นตัวเลือกเริ่มต้นที่น่าเชื่อที่สุดในเกือบทุกกรณีแล้ว การรันด้วย tsx เคยช่วยยกระดับคุณภาพชีวิตได้มาก แต่ก็ยังไม่สมบูรณ์อยู่ดี เรื่องการยืนยันชนิดข้อมูลตอนรันไทม์ที่ edge ก็ถูกแก้ไปเป็นส่วนใหญ่ด้วยเครื่องมืออย่าง zod, ts-rest และ trpc ทุกวันนี้การพัฒนาแบบฟูลสแตกด้วย Typescript ง่ายมากจริง ๆ
    • เรื่องจริงเลย พอถึงปี 2025 ecosystem ของ node ก็ใช้งานได้ดีพอด้วยค่าตั้งต้นเสียที ESM modules ทำงานได้ลื่นทั้งฝั่ง Node และ Typescript, Node รันไฟล์ .ts ได้ตรง ๆ และยังมี test runner พื้นฐานที่ดีติดมาให้ด้วย (รองรับ --watch) แพ็กเกจที่มีมาในตัวก็ดีขึ้นเรื่อย ๆ อย่าง node:fs/promises พอมี top-level await แล้ว งานพวก async loop ก็ง่ายขึ้นเยอะ กว่าจะทำให้ทุกคนยอมรับแนวทางที่ใช้งานได้จริงแบบนี้ได้ก็ใช้เวลานาน แต่ตอนนี้ประสบการณ์มันลื่นมากแล้ว
    • ผมเห็นด้วยเต็มที่กับการที่ Node รองรับ Typescript ได้โดยตรง ทุกวันนี้ vitest ช่วยอำนวยความสะดวกหลายอย่างก็จริง แต่ผมเคยเสียเวลาไปมากกับการเซ็ตสภาพแวดล้อมทดสอบสำหรับไฟล์ .ts ส่วน trpc กับ ts-rest ผมว่ามันเป็นคนละปัญหากัน ใช้ทั้งคู่ได้ แต่ในโปรดักชันผมเลี่ยง trpc เพราะผมไม่สามารถเป็นเจ้าของ URL ของ API ได้เอง และจัดการกับ URL เก่า ๆ รวมถึงการเลิกใช้อย่างเป็นธรรมชาติไม่ได้ ส่วน ts-rest ปกติผมก็มักจะเลือกแชร์ zod กับ type แล้วดูแลคู่ request/response ของ API เองมากกว่า แล้วทุกครั้งที่ trpc เป็นเครื่องมือแบบ RPC ชัด ๆ แต่ชื่อดันมี -rest ก็ยังขัดใจอยู่ดี
    • ต่อไปคงต้องรอดูว่า Sveltr จะย้าย codebase กลับมาเป็น Typescript อีกไหม
    • สงสัยว่านี่รองรับการรัน tsx ด้วยไหม ถึงจะลบ type ออกได้ แต่ JSX ก็ยังต้องแปลงเป็น JavaScript อยู่ดี เลยอยากรู้ว่าจัดการส่วนนั้นยังไง
    • ผมเพิ่งย้ายไป Python ไม่นานนี้เอง พอทุกอย่างมีมาให้ในตัว ก็พอใจมากกว่าเยอะ เพราะไม่ต้องมานั่งดีบักปัญหาประหลาดจากระบบที่ยังไม่สมบูรณ์หลาย ๆ จุด
  • ผมประทับใจกับพัฒนาการของ Node ในช่วงไม่กี่ปีที่ผ่านมามาก ดีที่ deno กับ bun มากระตุ้นให้ Node ลงมือปรับปรุงแบบจริงจังและมีความหมาย เพราะก่อนหน้านั้นเหมือนนิ่งอยู่พักใหญ่
    • อยากรู้ว่า Node เพิ่งมีอะไรดีขึ้นบ้าง การเปลี่ยนแปลงล่าสุดที่ผมจำได้ว่าใหญ่จริงคือการรองรับ import/export อย่างเป็นทางการ (ไม่แน่ใจว่ายังต้องใช้กลเม็ด .mjs อยู่ไหม) ผมห่างจาก ecosystem นี้ไปพักหนึ่ง เลยอยากรู้ว่าหลังจากนั้นมีอะไรเปลี่ยนไปบ้าง
    • ไม่แน่ใจว่าจริงแค่ไหนนะ จากโปรเจกต์ที่ผมเคยทำ ต่อให้ไม่มี deno หรือ bun ก็ไม่ได้กระทบอะไรเลย ของที่มีผลจริง ๆ ก็คือ Node LTS release และแม้แต่โปรเจกต์ใหม่ ๆ ตอนนี้ก็ยังใช้ node 20 กันอยู่
  • น่าเสียดายที่ Typescript ยังไม่ถูกรับใน node_modules (เกี่ยวข้อง: เอกสารทางการของ node.js). ถ้าอย่างนั้น dependency ของโปรเจกต์จะเป็นยังไง ผมเขียนไลบรารีสำหรับ data model ด้วย Typescript แล้วอยาก import เข้ามาในแอปทั้งแบบ Typescript เลย เลยสงสัยว่ากฎนี้ใช้เฉพาะกับแพ็กเกจ npm หรือใช้กับ dependency ทุกแบบกันแน่ ตรงนี้ยังมีโอกาสอยู่ ผมทำ runtime สำหรับรัน typescript (จริง ๆ คือ JS โดยรวม) ที่เขียนด้วย golang และ sobek ที่ทีม grafana ใช้ก็ดูเหมือนจะเหลือแค่เพิ่มความสามารถ type strip ก็พอ ผมรู้สึกว่าถ้ามี runtime ที่ยึด Typescript เป็นค่าเริ่มต้นแบบเต็มตัวออกมาสักตัว Node.js จะถูกผลักดันไปอีกขั้นจริง ๆ ไม่ต้องมีทั้ง transpiler, typescript-go หรือ rust (แต่ rust ก็ยังนิดหน่อย😉) ขอแค่มี parser ที่ดีและระบบที่ตาม source map กับ type ได้ในโหมดดีบักก็น่าจะพอ อย่างไรก็ดี ต้องขอชื่นชมและขอบคุณทีม Node กับผู้มีส่วนร่วมทุกคน เพราะ Node ที่เป็นมาตรฐานทำให้เหมือนพวกเราทุกคนได้เดินตามไปด้วย API สำหรับ embedding ก็เรียบง่ายและใช้งานสะอาดดี เลยสะดวกเวลาทำตัว standalone
    • ผมเคยคอมเมนต์แบบเดียวกันไว้ (อ้างอิง) มีส่วนที่บอกว่า “เพื่อไม่สนับสนุนให้เผยแพร่แพ็กเกจที่เขียนด้วย TypeScript ไปยัง npm” ซึ่งผมก็ลองกับแพ็กเกจ private แล้วแต่มันก็ยังไม่ทำงาน และ Node เองก็ไม่ได้สนใจฟิลด์ "private" เลย
    • ผมคิดว่าแพ็กเกจควรถูกคอมไพล์เป็น JavaScript ก่อนค่อยเผยแพร่ขึ้น npm ไม่มีเหตุผลที่ต้องอัปโหลด TypeScript ตรง ๆ ไปบน npm
  • ประเด็นที่เกี่ยวข้อง ผมก็เสียดายที่ไม่มีการรองรับ type strip ใน node_modules
    • นี่คือครึ่งหนึ่งของเหตุผลที่ผมรอฟีเจอร์นี้เลย ผมอยากเขียนไลบรารีด้วย TypeScript แล้วให้ typecheck ไปรันแค่ใน CI/CD จากนั้น import เข้ามาใน Node.js ได้ตรง ๆ
    • ผมว่าตัดสินใจถูกแล้ว TypeScript มี breaking change ค่อนข้างบ่อย ถ้ายังไม่ถูกทำให้เป็นมาตรฐาน ผมว่าทางแบบปัจจุบันดีกว่า
  • ผมไม่ได้ใช้ JS/TS หนักมาก แต่ก็สงสัยว่าทำไมไม่ใช้ Bun ไปเลย มันอาจไม่เหมาะกับทุกโปรเจกต์ โดยเฉพาะโปรเจกต์เก่า แต่โดยรวมผมรู้สึกว่า Bun เป็น runtime ที่ดีกว่า รัน TS ได้ตั้งแต่แรก, resolve dependency ได้เร็วกว่าเยอะ และใช้งานก็ดีมาก ส่วนตัวผมย้ายโปรเจกต์ Node เก่า ๆ ไป Bun หลายตัวแล้ว และแทบไม่ได้ใช้ Node อีกหลังจาก Bun ออกมา ถ้าผมเข้าใจอะไรผิดก็ช่วยบอกด้วย
    • ผมใช้แต่ Node มาเกือบ 8 ปี แล้วเพิ่งย้ายไป Deno ไม่นานนี้ การย้ายก็ไม่ได้ง่ายนัก ไม่ใช่เพราะมันใช้ไม่ได้จริง แต่เพราะกลัวว่าเมื่อไรจะมีบางอย่างพัง Node เองก็มีจุดน่าหงุดหงิดเยอะ แต่ก็ยังเป็นมาตรฐานโดยพฤตินัยของอุตสาหกรรม ecosystem ของ JS เองก็วุ่นวายพออยู่แล้ว นักพัฒนาหลายคนก็เหนื่อยกับ build tool, bundler หรือ runtime ใหม่ ๆ กันแล้ว ผมยังไม่คิดว่า Bun จะมีความเสถียรหรือการรองรับมากพอให้มั่นใจได้ และผมก็เคยเสียเวลาหลายวันเพราะแค่อัปเดต TS เวอร์ชันย่อยครั้งเดียวมาก่อน
    • ผมไม่ค่อยชอบไล่ตามกระแสใหม่ ๆ เท่าไร NodeJS เป็น runtime ที่ได้รับการรองรับดีที่สุดใน ecosystem ของ JS ผมคิดว่าทางเลือกที่เป็นค่าเริ่มต้นนั้นดีกว่า ผมชอบเลือกเทคโนโลยีที่ออกแนว ‘เรียบง่ายไม่หวือหวา’ มากกว่า
    • ตั้งแต่ Bun เปิดตัว ผมพยายามย้ายทั้งหมดหลายครั้งแล้ว แต่ทุกครั้งก็มักไปติดปัญหาหลีกเลี่ยงไม่ได้ตอนประมาณ 90% ครั้งล่าสุดมีทั้งบางไลบรารีที่ใช้ฟังก์ชัน napi ที่ยังไม่ถูก implement เลยใช้ไม่ได้ และปัญหาที่ตัวเลือก recursive ใน opendir ถูกเพิกเฉย เป็นต้น ผมกำลังรอให้ Bun ไล่ตามให้ทัน แต่ตอนนี้ยังไม่รู้สึกว่าพร้อมสำหรับใช้งานจริงในโปรเจกต์ใหญ่ ฟีเจอร์เฉพาะของ bun ตอนแรกก็ดูน่าสนใจ แต่พอใช้จริงยังรู้สึกไม่ถึงขั้น เอกสารก็ยังไม่คุณภาพเท่า Node.js
    • นี่คือปัญหาความเข้ากันได้ที่ผมเจอเวลาพยายามแทนที่ Node ด้วย Bun
  • ค่า localAddress ในการเชื่อมต่อ TCP ถูกมองข้าม
  • ไม่เข้ากันกับ Node module API (ตัวอย่าง: โปรเจกต์ spamscanner ใช้งานไม่ได้)
  • ปัญหา race เกี่ยวกับ EventEmitter (แก้ได้บางส่วนด้วย eventemitter2)
  • dev server ของ Svelte vites ค้างเป็นบางครั้งจนต้องลบ node_modules แล้วติดตั้งใหม่

    • ผมลองใช้ฟีเจอร์ TS และ test runner ของ Node เองแล้ว แต่ก็ยังไม่ดีเท่า Bun ตอนนี้เวลาจะใช้ฟีเจอร์พวกนี้ผมก็ยังใช้ Bun อยู่ จากการอยู่ใน ecosystem ของ Node ผมได้เรียนรู้ว่าการจับคู่เครื่องมือที่แต่ละตัวถนัดเข้าด้วยกัน ดีกว่าทุ่มทั้งหมดให้ตัวเดียว

      • Bun.js: ใช้เป็น Node runtime สำหรับรัน TS และการทดสอบ ลองมาหลายแบบแล้วทั้ง TSX, TS-Node, ตัว Node เอง ฯลฯ

      • NPM: ใช้รันสคริปต์สำหรับ tooling

      • PNPM: ใช้ติดตั้ง dependency (รู้สึกว่าดีที่สุดเมื่อเทียบกับ npm, yarn, bun)

      • Biome.js: ใช้ linting ดีที่สุดในบรรดาเครื่องมือ lint ที่ผมเคยใช้มา

  • สิ่งที่ดีมากของการเปลี่ยนแปลงครั้งนี้คือมันทำได้ด้วย “type stripping” อย่างเดียว จึงไม่ต้องพึ่ง source map และในโปรดักชันแทบจะเป็น zero-cost แบบสมบูรณ์ ทีม Node ทำได้ยอดเยี่ยมจริง ๆ
  • มีการเปิดฟังก์ชัน type strip (import { stripTypeScriptTypes } from 'node:module') ออกมาให้ใช้ด้วย ถ้าจะทำเว็บแอปเล็ก ๆ ที่ไม่มี frontend dependency จะเขียนทั้งระบบเป็น typescript แล้วเสิร์ฟสคริปต์ฝั่ง frontend โดยลบเฉพาะ type ออกก็ได้ (ตัวอย่างโปรเจกต์)
  • การเปลี่ยนแปลงนี้ทำให้บริษัทของพวกเราเริ่มย้ายไป Typescript ได้เสียที เราเปลี่ยนหลายบริการไปเป็น TS พร้อมกัน และบางส่วนก็ยังอยู่ระหว่างทำ ถือว่าได้ประโยชน์มาก
  • ดูเหมือนว่าวิธีทำงานคือเอาข้อมูล type ออกเท่านั้น หมายความว่ามันช่วยลดขั้นตอน transpile ไปหนึ่งขั้น แต่ไม่ได้เพิ่มความปลอดภัยอะไร
    • เป้าหมายหลักด้านการออกแบบของ TypeScript คือ ถ้าตัด syntax ที่เกี่ยวกับ type ออก ผลลัพธ์จะต้องเป็นไฟล์ JavaScript ที่ถูกต้อง TS compiler ไม่ได้สร้างโค้ดขึ้นมาเอง (ต่างจากอย่าง PureScript) แล้วก็ค่อยให้ type checker อย่าง tsc ตรวจแบบสถิต และข้อมูล type จะถูกลบทิ้ง Python เองก็เพิกเฉยต่อ type annotation ตอนรันไทม์ และ Java ก็มีลักษณะที่ข้อมูล type บางส่วน เช่น generics ถูกลบออกจาก bytecode เช่นกัน
    • ประโยคที่ว่า “อย่างน้อยมันก็แค่ลดขั้นตอน transpile แต่ไม่ได้ทำให้ปลอดภัยขึ้น” อาจทำให้เข้าใจคลาดเคลื่อนได้ การที่ Node รัน TS ได้ตรง ๆ ไม่ได้เพิ่มความปลอดภัยจาก type checking โดยตรงก็จริง แต่ type checking ยังทำแยกได้ผ่าน editor หรือเครื่องมืออื่น ๆ และการที่ Node รองรับการรัน TS ตรง ๆ ก็ช่วยลดอุปสรรคในการเริ่มใช้ TS ลงมาก ซึ่งช่วยเรื่อง type safety ทางอ้อมได้
    • TypeScript ไม่เคยสัญญาว่าจะทำให้ปลอดภัยขึ้นแบบรับประกัน นี่เป็นความเข้าใจผิดที่พบได้บ่อย TS ไม่มี runtime mode หรือข้อมูล runtime อะไรอยู่แล้ว และถ้าไม่รัน type checker ต่อให้มี type error ร้ายแรงก็ยังรันได้ตามปกติ ถ้าจะพูดแบบเคร่งครัด Typescript ก็ใกล้เคียง linter มากกว่า
    • ผมคิดว่าการรันสคริปต์ได้ตรง ๆ โดยไม่ต้อง build/transpile ก่อนนั้นสะดวกมาก ถ้าต้องการ typecheck ค่อยรัน tsc ก็เข้าท่าดีสำหรับผม
    • ตอนนี้ในโปรเจกต์ผมก็ใช้เซ็ตอัปแบบเดียวกันผ่าน tsx คือรันได้โดยไม่ต้อง build/transpile ก่อน ซึ่งมีประโยชน์มากตอนพัฒนา ใช้ --watch ของ tsx ให้รันเซิร์ฟเวอร์จากซอร์ส TS ตรง ๆ แล้วรีสตาร์ตอัตโนมัติเมื่อมีการเปลี่ยนแปลง ต่อไปก็น่าจะทำสภาพแวดล้อมคล้ายกันได้ด้วย nodemon กับฟีเจอร์ที่มีมาใน Node เอง ถ้าจะให้มี type checking ใน runtime เลยจริง ๆ คงต้องรองรับระดับ v8 ซึ่งแทบจะเท่ากับเขียนใหม่ทั้งชุด
  • ในทางปฏิบัติแล้วมันไม่ได้รัน Typescript ทั้งหมด แต่รองรับเพียงบางส่วนย่อยเท่านั้น เลยอาจรู้สึกได้ว่าพาดหัวค่อนข้างเกินจริง และการเปลี่ยนแปลงแบบนี้ก็อาจทำให้ TS ถูกใช้แค่เหมือน linter จนความสามารถ TS ที่ทรงพลังหลายอย่างซึ่งทำไม่ได้ด้วยการ strip type ถูกลดบทบาทลง
    • อยากรู้จริง ๆ ว่าฟีเจอร์อะไรของ TS ที่ strip ไม่ได้บ้าง นอกจาก enum แล้ว มีกรณีใช้งานจริงอะไรอีกที่คนใช้กัน?