Node.js अब बिना अतिरिक्त सेटअप के TypeScript फ़ाइलें चला सकता है

• Node.js को TypeScript फ़ाइलें सीधे चलाने के लिए बेहतर बनाया गया है
• अब अतिरिक्त सेटअप या ट्रांसपाइलिंग के बिना .ts फ़ाइलें सीधे चलाई जा सकती हैं
• डेवलपर्स अब tsconfig.json या अलग bundler इंस्टॉल किए बिना काम की दक्षता बढ़ा सकते हैं
• यह फीचर Node.js v22.18.0 (LTS) संस्करण से आधिकारिक रूप से शामिल किया गया है
• इससे JavaScript और TypeScript डेवलपमेंट के बीच की सीमा और कम होने की उम्मीद है

---

Node.js में TypeScript को सीधे चलाने का समर्थन

• Node.js ने हाल ही में v22.18.0 (LTS) संस्करण में TypeScript फ़ाइलों (.ts) को बिना अलग सेटअप या टूल के सीधे चलाने की सुविधा जोड़ी है
• पहले TypeScript कोड चलाने के लिए ts-node, esbuild, Babel जैसे बाहरी transpiler या bundler की ज़रूरत होती थी, लेकिन अब Node.js खुद TypeScript कोड को पहचानकर चला सकता है
• इस फीचर की मदद से डेवलपर्स tsconfig.json configuration फ़ाइल या अतिरिक्त लाइब्रेरी के बिना .ts फ़ाइलों को सीधे Node.js में चला सकते हैं
• prototyping, experimental development और script execution जैसे कामों में productivity और डेवलपमेंट की सुविधा काफ़ी बढ़ेगी
• JavaScript और TypeScript प्रोजेक्ट्स के बीच इंटरऑपरेबिलिटी मज़बूत होने और नए डेवलपर्स के लिए प्रवेश बाधा कम होने की उम्मीद है

अन्य उल्लेखनीय बदलाव

• esm: import.meta.main लागू किया गया
• fs: AsyncIterator आधारित fs event handling में सुधार
• permission: child process चलाते समय permission model flag पास करने का समर्थन
• sqlite: readBigInts विकल्प जोड़ा गया
• src/permission: permission.has(addon) का समर्थन
• url: fileURLToPathBuffer API जोड़ी गई
• watch: --watch-kill-signal flag जोड़ा गया
• worker: Worker ऑब्जेक्ट को async disposable के रूप में बेहतर बनाया गया

कमिट और दस्तावेज़ से जुड़े अपडेट

• अनावश्यक कोड हटाना, build environment और toolchain की सफ़ाई, तथा npm 10.9.3 upgrade शामिल
• globals.md, child_process.md, http2 आदि दस्तावेज़ों में stability indicators और RFC numbers के विवरण सुधारे गए
• कई नए tests जोड़े गए और bug fixes शामिल किए गए

वितरण फ़ाइलें

• Windows, macOS(Intel/Apple Silicon), Linux(x64, ARM, PPC, s390x, AIX) के लिए installer और binaries उपलब्ध
• source code और पूरी release files को Node.js के आधिकारिक distribution page से डाउनलोड किया जा सकता है
• API documentation को v22.18.0 के अनुसार अपडेट किया गया है

[aliveornot]

वाह, मन को सच में राहत मिली... उम्मीद है यह जल्दी से अच्छी तरह अपनाया जाएगा

[tested]

सरल स्क्रिप्ट चलाने के लिए यह ठीक लग सकता है, लेकिन लाइव प्रोजेक्ट्स में इसकी कई सीमाएँ हैं, इसलिए इसका इस्तेमाल करने की नौबत शायद कम ही आएगी.

ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT त्रुटियों की वजह से extension और path भी ठीक से मिलाने पड़ते हैं,
और NestJS जैसे cases में, जहाँ "emitDecoratorMetadata" सेटिंग के साथ TypeScript build support चाहिए, ऐसी सुविधाएँ इस्तेमाल नहीं की जा सकतीं, तो...

[kimjeongwonn]

क्या --experimental-strip-types डिफ़ॉल्ट रूप से लागू होगा?

[click]

वैसे भी मैं enum इस्तेमाल नहीं करता, इसलिए मेरे हिसाब से सिर्फ type removal वाला व्यवहार ही इसे अच्छी तरह चलाने के लिए काफी था।

[crawler]

यह बहुत सुविधाजनक हो जाएगा!

[honglu]

लाइक दबाने से खुद को रोक नहीं पा रहा हूँ।

मुझे लगा था कि --no-experimental-strip-types फ्लैग के साथ भी यह काफी अच्छा है।

लेकिन यह उससे भी बेहतर लग रहा है.

[GN⁺]

Hacker News की राय

• node:test के साथ Node.js में अब मुझे लगता है कि ज़्यादातर मामलों में Node.js लगभग एक भरोसेमंद default विकल्प बन गया है। tsx के साथ चलाना जीवन को काफी आसान बनाता था, लेकिन वह भी पूरी तरह पर्याप्त नहीं था। zod, ts-rest, और trpc जैसे tools edge पर runtime type assertions की समस्या को काफी हद तक हल कर रहे हैं, और आजकल full-stack Typescript development सच में बहुत आसान हो गया है
  • बिल्कुल सही। 2025 तक आते-आते आखिरकार node ecosystem default settings के साथ भी इस्तेमाल लायक हो गया है। ESM modules Node और Typescript दोनों में अब बस ठीक से काम करते हैं, Node .ts files को सीधे चला सकता है, और इसमें एक अच्छा built-in test runner भी है (--watch support के साथ)। built-in packages भी बेहतर हो रहे हैं। node:fs/promises जैसे मामलों में, top-level await की वजह से async loop काम भी काफी आसान हो गया है। सबको इसे व्यावहारिक रूप से अपनाने के लिए मनाने में बहुत समय लगा, लेकिन अब माहौल सच में काफी सुखद हो गया है
  • मैं Node में Typescript के direct support के पक्ष में हूं। vitest आजकल बहुत चीज़ें आसान बना देता है, लेकिन .ts file test environment सेट करने में मैंने वाकई बहुत समय गंवाया है। trpc और ts-rest पूरी तरह अलग समस्याएं हल करते हैं। दोनों इस्तेमाल किए जा सकते हैं, लेकिन production में मैं trpc से बचता हूं क्योंकि उसके मामले में API URL पर मेरा सीधा नियंत्रण नहीं होता, और पुराने URLs को स्वाभाविक तरीके से manage और deprecate करना मुश्किल होता है। ts-rest में भी मैं आम तौर पर zod और types साझा करके API request/response pairs को खुद manage करना पसंद करता हूं। और trpc साफ़ तौर पर एक RPC tool है, इसलिए उसके नाम में -rest देखना हर बार खटकता है
  • अब देखना होगा कि Sveltr आगे चलकर अपना codebase फिर से Typescript में शिफ्ट करता है या नहीं
  • मुझे जानना है कि क्या यह tsx भी चलाता है। types हटाने के बाद भी JSX को JavaScript में बदलना पड़ता है, इसलिए वही हिस्सा जानने की जिज्ञासा है
  • मैंने हाल ही में Python पर switch कर लिया। सब कुछ built-in होने की वजह से अधूरे system की अजीब समस्याओं को debug नहीं करना पड़ता, और मैं इससे कहीं ज़्यादा संतुष्ट हूं
• पिछले कुछ सालों में Node ने जो प्रगति दिखाई है, उससे मैं काफी प्रभावित हूं। अच्छा लगा कि deno और bun ने Node को प्रेरित किया ताकि वह केंद्रित और सार्थक सुधार कर सके। एक समय तक इसमें ठहराव था
  • मुझे जिज्ञासा है कि हाल में Node में कौन-कौन से सुधार हुए हैं। आखिरी meaningful improvement जो मुझे याद है, वह import/export का proper support था (हालांकि पता नहीं .mjs hack अभी भी चाहिए या नहीं)। मैं कुछ समय से ecosystem से दूर हूं, इसलिए उसके बाद क्या बदला यह जानना चाहता हूं
  • मुझे संदेह है कि सच में ऐसा हुआ भी था। जिन projects में मैं शामिल रहा हूं, उनमें deno या bun के बिना भी सब ठीक था। व्यवहारिक रूप से सबसे महत्वपूर्ण चीज़ सिर्फ node LTS releases ही रहे हैं, और नए projects भी अभी तक node 20 version ही इस्तेमाल कर रहे हैं
• यह अफ़सोस की बात है कि Typescript को node_modules में स्वीकार नहीं किया जाता (संबंधित: node.js आधिकारिक दस्तावेज़). तो फिर project dependencies का क्या होगा, यह जानने की जिज्ञासा है। मैंने data model के लिए एक library Typescript में लिखी है, और मैं उसे अपनी app में Typescript के रूप में import करना चाहता हूं। जानना चाहता हूं कि यह नियम सिर्फ npm packages पर लागू होता है या सभी dependencies पर। यहां एक अवसर है। मैंने typescript (असल में पूरे JS) execution के लिए एक golang-based runtime बनाया है, और Grafana team द्वारा इस्तेमाल किया जाने वाला sobek भी शायद type strip functionality जोड़ने भर से काम चला ले। अगर एक भी runtime ऐसा आ जाए जो पूरी तरह Typescript को default के रूप में अपनाए, तो मुझे लगेगा कि Node.js में सचमुच एक क्रांति आ जाएगी। transpiler की ज़रूरत नहीं, typescript-go की ज़रूरत नहीं, rust की भी ज़रूरत नहीं (हालांकि rust थोड़ा-सा 😉), बस एक अच्छा parser और ऐसा system काफ़ी होगा जो debugging mode में source maps और types को track कर सके। खैर, Node team और सभी contributors को सम्मान और धन्यवाद। standard के रूप में Node होने की वजह से लगता है कि हम सब उसी के पीछे-पीछे चल रहे हैं। embedding API भी सरल है और usability भी साफ़-सुथरी है, इसलिए standalone बनाते समय भी सुविधाजनक है
  • मैंने भी यही comment छोड़ा था (संदर्भ)। वहां “Typescript में लिखे packages को npm पर publish न करने के लिए प्रोत्साहित करना” वाली बात है, और मैंने private package के साथ भी इसे आज़माया, लेकिन वह भी काम नहीं किया, और Node "private" field की परवाह भी नहीं करता
  • मेरा मानना है कि packages को npm पर publish करने से पहले JavaScript में compile करके ही भेजना चाहिए। मुझे नहीं लगता कि Typescript को ज्यों का त्यों npm पर डालने की कोई वजह है
• संबंधित issue मुझे अफ़सोस है कि node_modules में type strip support नहीं है
  • इस feature से मेरी आधी उम्मीद इसी वजह से थी। मैं चाहता था कि libraries Typescript में लिखूं, typecheck सिर्फ CI/CD में चलाऊं, और फिर उन्हें सीधे Node.js में import कर सकूं
  • मुझे यह सही फैसला लगता है। Typescript में breaking changes काफ़ी बार आते हैं। जब तक यह standardize नहीं हो जाता, मुझे लगता है कि मौजूदा तरीका बेहतर है
• मैं JS/TS का बहुत भारी उपयोगकर्ता नहीं हूं, लेकिन मुझे समझना है कि क्या सीधे Bun इस्तेमाल करना बेहतर नहीं है। हर project नया शुरू नहीं होता, यह सही है, लेकिन फिर भी Bun मुझे overall बेहतर runtime लगा। TS execution शुरू से मिलता है, dependency resolution कहीं तेज़ है, और usability भी शानदार है। मैंने व्यक्तिगत रूप से बहुत से पुराने Node projects को Bun पर migrate किया है, और Bun public होने के बाद से Node लगभग इस्तेमाल ही नहीं किया। अगर मैं कहीं गलत हूं, तो कृपया बताएं
  • मैं लगभग 8 साल तक सिर्फ Node इस्तेमाल करता रहा, फिर हाल में Deno पर गया। यह switch आसान नहीं था, और वजह यह नहीं थी कि चीज़ें चलती नहीं थीं, बल्कि यह डर था कि पता नहीं कब क्या काम करना बंद कर दे। Node में कमियां ज़रूर हैं, लेकिन फिर भी वही industry का de facto standard है। JS ecosystem खुद इतना अव्यवस्थित है कि बहुत से developers नए build tools, bundlers, और runtimes से थक चुके हैं। Bun में अभी शायद उतनी stability या support नहीं जमा है कि वह पूरी तरह convincing लगे। पहले TS के एक minor update के कारण मैंने कई दिनों तक समस्याएं सुलझाई थीं
  • मुझे हर नई trend के पीछे भागना खास पसंद नहीं। NodeJS, JS ecosystem में सबसे अच्छी support वाला runtime है। मुझे लगता है default विकल्प के साथ जाना ज़्यादा बेहतर है। मैं तथाकथित ‘boring’ technologies चुनना पसंद करता हूं
  • Bun के release होने के बाद मैंने कई बार पूरी तरह switch करने की कोशिश की, लेकिन हर बार लगभग 90% तक पहुंचकर किसी न किसी अपरिहार्य समस्या से टकरा गया। आखिरी कोशिश में कुछ libraries में napi functions implement नहीं थे, इसलिए वे नहीं चले, और opendir options में recursive ignore होने जैसी समस्याएं भी थीं। मैं Bun के catch-up का इंतज़ार कर रहा हूं, लेकिन अभी तक यह बड़े projects में production use के लिए तैयार नहीं लगता। Bun-specific features पहली नज़र में अच्छे लगते हैं, लेकिन व्यवहार में कमज़ोर महसूस होते हैं। documentation भी Node.js जितनी उच्च गुणवत्ता की नहीं है
  • Node को Bun से replace करने की कोशिश में मुझे ये compatibility समस्याएं मिलीं।
• TCP connections में localAddress ignore हो जाता है
• Node module API के साथ incompatibility (उदाहरण: spamscanner project काम नहीं करता)
• EventEmitter से जुड़ी race problems (आंशिक समाधान: eventemitter2 के साथ)
• Svelte vites dev server कभी-कभी अटक जाता था, और फिर node_modules हटाकर दोबारा install करना पड़ता था

  • मैंने Node की अपनी TS और test runner features इस्तेमाल की हैं, लेकिन वे अभी Bun जितनी अच्छी नहीं हैं। फिलहाल ऐसे features के लिए मैं Bun ही इस्तेमाल कर रहा हूं। Node ecosystem में मैंने सीखा है कि एक ही चीज़ पर all-in जाने के बजाय, अलग-अलग tools को उनकी specialization के हिसाब से मिलाकर इस्तेमाल करना बेहतर होता है।

    • Bun.js: Node runtime के लिए, TS execution और testing में उपयोग। TSX, TS-Node, Node खुद आदि कई विकल्प आज़मा चुका हूं

    • NPM: tooling scripts चलाने के लिए उपयोग

    • PNPM: dependencies install करने के लिए उपयोग। (npm, yarn, bun की तुलना में सबसे बेहतर लगता है)

    • Biome.js: linting के लिए। अब तक इस्तेमाल किए गए किसी भी linting tool से बेहतर

• यह बहुत अच्छी बात है कि यह सुधार सिर्फ “type stripping” से हासिल किया गया है, इसलिए source maps की ज़रूरत नहीं पड़ती और production में यह पूरी तरह zero-cost हो जाता है। Node team ने सच में अच्छा काम किया है
• type strip function (import { stripTypeScriptTypes } from 'node:module') भी expose की गई है। frontend dependencies के बिना simple webapp बनाते समय, पूरी app को typescript में बनाया जा सकता है और frontend scripts serve करते समय सिर्फ types हटा दिए जाएं (उदाहरण project)
• इस बदलाव की वजह से हमारी company भी आखिरकार Typescript पर जा सकी। हमने कई services को एक साथ TS में migrate किया, और कुछ पर काम अभी जारी है। यह बहुत बड़ी उपलब्धि है
• ऐसा लगता है कि यह काम type information हटाने के तरीके से होता है। यानी यह सिर्फ एक transpile step कम कर देता है, सुरक्षा के लिहाज़ से कोई सुधार नहीं करता
  • Typescript का प्रमुख design goal यही है कि type-related syntax हटाने के बाद output एक valid JavaScript file हो। TS compiler code generate नहीं करता (जैसे PureScript करता है, वैसा नहीं)। tsc जैसे typechecker के ज़रिए static checking होती है, और type information हट जाती है। Python भी runtime पर type annotations को ignore करता है, और Java में भी bytecode में कुछ type information जैसे generics आदि हट जाते हैं
  • “कम-से-कम transpile step कम हो जाता है, लेकिन safety नहीं बढ़ती” यह बात थोड़ी भ्रामक हो सकती है। Node का TS को सीधे चलाना typechecking safety नहीं बढ़ाता, यह सही है, लेकिन typechecking editor या दूसरे tools में अलग से की जा सकती है। Node जब सीधे TS execution को support करता है, तो TS adoption की barrier काफी कम हो जाती है, और अप्रत्यक्ष रूप से type safety को मदद मिलती है
  • Typescript ने कभी safety improvement की गारंटी देने का वादा नहीं किया था। यह आम ग़लतफ़हमी है। TS में runtime mode या information जैसी कोई चीज़ नहीं थी, इसलिए अगर आप typechecker नहीं चलाते, तो गंभीर type errors होने पर भी code वैसे ही चल सकता था। सख्ती से कहें तो Typescript एक linter के ज़्यादा करीब है
  • build/transpile के बिना scripts को सीधे चलाना मुझे बेहद सुविधाजनक लगता है। typecheck की ज़रूरत हो तो tsc चला लेना मेरे लिए ठीक बैठता है
  • हम project में tsx का इस्तेमाल करके ऐसा ही setup चला रहे हैं, जहां build/transpile के बिना execution हो जाता है। development के दौरान यह बहुत उपयोगी है। tsx के --watch की मदद से TS source से सीधे server चलाते हैं, और बदलाव होने पर वह अपने-आप restart हो जाता है। आगे चलकर शायद nodemon और Node की built-in features से ऐसा ही माहौल बनाया जा सके। अगर runtime में typechecking तक करनी हो, तो v8 level पर support चाहिए होगा, और यह लगभग पूरे rewrite जितना बड़ा काम होगा
• असल में यह पूरे Typescript को execute नहीं करता, बल्कि उसके सिर्फ एक subset को support करता है। इसलिए शीर्षक थोड़ा बढ़ा-चढ़ा हुआ लग सकता है। ऐसी आशंका है कि यह बदलाव TS को सिर्फ linter की तरह इस्तेमाल करने की ओर धकेल सकता है, और TS की वे कई शक्तिशाली features जो सिर्फ type strip से लागू नहीं हो सकते, वे हाशिए पर चली जाएंगी
  • मैं जानना चाहूंगा कि TS में ऐसी कौन-सी features हैं जिन्हें strip नहीं किया जा सकता। enum के अलावा वास्तव में इस्तेमाल होने वाले कौन-से cases हैं?