Node.js में TypeScript के लिए प्रयोगात्मक सपोर्ट जोड़ा गया

 (github.com/nodejs)
3 पॉइंट द्वारा GN⁺ 2024-07-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें

मॉड्यूल: --experimental-strip-types जोड़ा गया

  • Node.js में TypeScript फ़ाइलें चलाना संभव

    • --experimental-strip-types फ़्लैग सेट करने पर TypeScript फ़ाइलें चलाई जा सकती हैं
    • Node.js, TypeScript source code को JavaScript source code में बदल देता है
    • रूपांतरण के दौरान type check नहीं किया जाता, और types हटा दिए जाते हैं

  • प्रेरणा

    • TypeScript फ़ाइलों को बिना external dependency या loader के चलाने योग्य बनाना महत्वपूर्ण है
    • उपयोगकर्ता node foo.ts चला सकें, यह लक्ष्य है

  • type stripping का मतलब

    • type stripping का अर्थ है सभी types हटाकर input को JavaScript module में बदलना
    • उदाहरण: const foo: string = "foo"; को const foo = "foo"; में बदला जाता है

  • @swc/wasm-typescript चुनने का कारण

    • इसकी सादगी
    • दूसरे tools में Rust या Go जोड़ना पड़ता है, लेकिन @swc/wasm-typescript के लिए सिर्फ़ छोटा package, wasm और js फ़ाइलें चाहिए
    • Deno में भी इस्तेमाल होने के कारण इस पर भरोसा किया जा सकता है

  • सीमाएँ

    • Enum, namespace जैसे TypeScript-विशिष्ट फीचर transform नहीं होते
    • extension के बिना import सपोर्ट नहीं है

  • आगे की योजना

    • इसे native layer में लागू किए जाने की संभावना है
    • source map support जोड़ा जा सकता है

GN⁺ का सार

  • यह Node.js में TypeScript फ़ाइलें चलाने योग्य बनाने वाली नई सुविधा के बारे में बताता है
  • TypeScript फ़ाइलों को JavaScript में बदलकर चलाया जा सकता है, लेकिन type check नहीं होता
  • इससे उपयोगकर्ता बिना external dependency के TypeScript फ़ाइलें चला सकते हैं, जिससे development environment सरल होता है
  • यह फीचर @swc/wasm-typescript का उपयोग करके लागू किया गया है, और भविष्य में native layer implementation पर भी विचार हो रहा है
  • यह TypeScript और JavaScript को मिलाकर इस्तेमाल करने वाले projects के लिए उपयोगी हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-26
Hacker News की राय

  • TypeScript के type हटाना, TypeScript के syntax के बिना संभव नहीं है। type removal token-level का काम नहीं है, और TypeScript syntax लगातार बदलता रहा है

    • उदाहरण के लिए, foo < bar & baz > ( x ) को TypeScript 1.5 में अलग तरह से interpret किया जाता था
    • नए TypeScript features इस्तेमाल करने के लिए या तो JS में compile करना होगा या Node version को लगातार latest रखना होगा
    • Node LTS release इस्तेमाल करने वालों के लिए यह समझौता मुश्किल हो सकता है

  • अगर Node.js सीधे TypeScript files चला सके, तो TypeScript compiler को type हटाकर JavaScript में बदलने की ज़रूरत नहीं होगी

    • यह स्थिति Python जैसी है
    • Python में कई type checker मौजूद हैं, और सब एक ही type hint syntax इस्तेमाल करते हैं, लेकिन अलग semantics लागू करते हैं
    • JavaScript में TypeScript ही एकमात्र लोकप्रिय type checker बन गया है
    • Python में कुछ लोग type hints को comment की तरह भी इस्तेमाल करते हैं
    • अगर Node.js में types को ignore करने की सुविधा आए, तो JavaScript में भी यह संभव होगा

  • अगर यह feature default बन जाए, तो NPM ecosystem कैसे प्रतिक्रिया देगा, यह जानने की जिज्ञासा है

    • NPM module publish करते समय क्या CJS और EJS versions को बनाना जारी रखेंगे, या engine: nodejs >= 25 को package.json में जोड़कर build step छोड़ देंगे, यह सोचने वाली बात है
    • व्यक्तिगत रूप से चाहता हूँ कि TS में लिखे गए NPM modules अब dist/.cjs देना बंद कर दें
    • build step छोड़ देना NPM contributors के लिए आकर्षक होगा
    • इससे NPM ecosystem में ripple effect आ सकता है
    • अगर Node.js यह feature experimental flag के बिना दे दे, तो उम्मीद है कि सभी consumers TS files स्वीकार करेंगे
    • इससे Firefox और Safari पर भी TS files स्वीकार करने का दबाव पड़ सकता है
    • व्यक्तिगत रूप से मुझे यह पसंद है कि JS compiler, TS type annotations को हटा दे
    • अगर Node .ts files स्वीकार करे, तो transpilation step हटाया जा सकता है

  • अगर Node, JS में types को inspect कर सके, तो यह बड़ा फ़ायदा होगा

    • Python में pydantic जैसे tools हैं, जो types को inspect करके validations बनाते हैं
    • इससे एक ही standard notation के साथ type checking, runtime data validation, API generation, और API documentation generation संभव हो जाती है
    • अभी JS में इसके लिए zod जैसे tools की ज़रूरत पड़ती है

  • Bun का developer experience (DX) इस क्षेत्र में बेजोड़ है, और ज़्यादातर use cases पूरे हो जाते हैं

    • Node में import के समय extension ज़रूरी न हो, ऐसा configure नहीं किया जा सकता, और tsc को .js extension अपने-आप जोड़ने के लिए भी configure नहीं किया जा सकता
    • native TypeScript support इससे मदद कर सकती है, लेकिन Bun के user experience या performance की बराबरी करना मुश्किल होगा

  • TypeScript मुझे बहुत पसंद है और मैं लंबे समय से TypeScript runtime चाहता रहा हूँ

    • मैंने Java इसलिए छोड़ा क्योंकि मुझे ज़्यादा features वाला type system और gradual typing चाहिए था
    • npm ecosystem की कमियों के बावजूद, libraries इस्तेमाल करना कम बोझिल और ज़्यादा मज़ेदार लगता है
    • Rust language spectrum के दूसरे छोर पर है, लेकिन वैसा ही एहसास देता है
    • JIT गलत शब्द था; मेरा मतलब JVM और V8 के startup time और runtime के अंतर से था

  • मेरी पसंदीदा deno feature अब सीधे Node में आ रही है

    • esbuild install किए बिना types हटाए जा सकेंगे, इसे लेकर मैं बहुत उत्साहित हूँ
    • हाल में मैं Python को ज़्यादा पसंद कर रहा था, लेकिन type system के मामले में TypeScript, Python से बेहतर है
    • बड़े scripts में types होने पर फ़ायदा और भी ज़्यादा मिलता है

  • Node के लिए यह बहुत महत्वपूर्ण महीना रहा है

    • v22.5.0 में node:sqlite जोड़ा गया, और अब TypeScript support भी आ रहा है
    • Node की दिशा मुझे पसंद आ रही है

  • मैं ही PR का लेखक हूँ, AMA

  • बहुत पहले मैंने backend काम के लिए Node.js इस्तेमाल करना शुरू किया था, और यह PHP की तुलना में कई फ़ायदे देता था

    • Node थोड़ा झंझटी था, और इसे मनचाही भाषा जैसा बनाने के लिए काफ़ी चीज़ें जोड़नी पड़ती थीं
    • फिर मैंने Golang इस्तेमाल करना शुरू किया, और type safety की वजह से coding आसान लगी
    • TypeScript अच्छा विकल्प है, लेकिन आखिरकार यह एक और अतिरिक्त layer ही है
    • Node इस्तेमाल करने का बड़ा फ़ायदा prototyping की speed है, और TypeScript के इस्तेमाल से यह फ़ायदा कुछ हद तक कम हो सकता है