एक Node, TypeScript, TS-Node और ESM अनुभव जो काम करता है

मूल लेख ↗ Hacker News चर्चा ↗

Node.js developers TypeScript, `ts-node`, और ECMAScript modules को एक साथ इस्तेमाल करते समय काफ़ी friction का वर्णन करते हैं, खासकर जब projects में monorepos, Jest जैसे testing frameworks, और complex dependency trees शामिल हों। कई लोगों का कहना है कि “बस काम करने” वाले boilerplate configs असली complexity को छिपा देते हैं, और वे `tsx`, Vitest, या Deno और Bun जैसे alternative runtimes को प्राथमिकता देते हैं जो TypeScript और ESM support को अधिक seamless बनाने का लक्ष्य रखते हैं। दूसरे इससे असहमत हैं, और कहते हैं कि सही configuration के साथ यह stack reliable बनाया जा सकता है, लेकिन वे यह भी मानते हैं कि poor interoperability, shifting standards, और module resolution पर कमजोर documentation ने मौजूदा ecosystem को असामान्य रूप से brittle बना दिया है.

Node + TypeScript + ESM पर समग्र भावना

  • कई टिप्पणीकार कहते हैं कि Node + TypeScript + ts-node + ESM का कॉम्बिनेशन भ्रमित करने वाला, नाज़ुक, और edge cases से भरा हुआ है।
  • दूसरे लोग बताते हैं कि उनके लिए यह न्यूनतम config के साथ “बस काम करता है,” और उन्हें संघर्ष समझ में नहीं आता।
  • कई लोग ज़ोर देते हैं कि दर्द अक्सर तब सामने आता है जब आप कई packages, subpath imports, test runners, या monorepos जोड़ते हैं, toy projects में नहीं।

ts-node बनाम tsx और अन्य TS runners

  • ts-node के drop-in replacement के रूप में tsx के लिए मज़बूत समर्थन है: तेज़, बेहतर ESM handling, सरल defaults।
  • कुछ लोगों को पहले tsx के साथ समस्याएँ थीं (जैसे Playwright, coverage), लेकिन वे बताते हैं कि हाल के v4 releases ने इनमें से कई को ठीक कर दिया है।
  • अन्य विकल्पों में शामिल हैं: esno (अब essentially tsx का alias), tsm, node-dev, esyes।
  • कुछ लोग runtime transpilers से पूरी तरह बचते हैं, और tsc --build --watch के साथ compiled JS चलाना पसंद करते हैं।

Testing, tooling, और monorepos

  • Jest + TypeScript + ESM को बार-बार दर्दनाक बताया गया है; Vitest को अक्सर एक smoother alternative के रूप में recommend किया जाता है।
  • Node का built-in test runner promising माना जाता है, लेकिन TS loaders और tools के साथ integration अभी भी uneven है।
  • TypeScript, ESLint, Jest, और mixed ESM/CJS वाले monorepos को “voodoo” और fragile कहा गया है; कुछ लोग ऐसे templates साझा करते हैं जो उनके लिए काम करते हैं।

Configuration बनाम समझ

  • इस बात पर बहस कि “बस ये config files copy कर लो” बनाम यह सीखो कि हर option क्या करता है।
  • कुछ लोग कहते हैं कि working examples सबसे अच्छा starting point हैं; दूसरे कहते हैं कि इससे “cargo cult” configs बनती हैं जो upgrades पर टूट जाती हैं।
  • शिकायतें कि TS/Node ecosystem में अच्छे “explanation” docs की कमी है जो बताएं कि module resolution और tsconfig options कैसे interact करते हैं, खासकर ESM के साथ।

ESM design और ecosystem friction

  • कई लोग Node की ESM implementation को ecosystem fractures के लिए ज़िम्मेदार मानते हैं (CJS/ESM incompat, type: module, __dirname का नुकसान, subpath exports issues)।
  • दूसरे तर्क देते हैं कि TypeScript और Jest जैसे tools ESM support देने में धीमे रहे, जबकि वर्षों से चेतावनी दी जा रही थी।
  • कुछ लोग ESM design की कड़ी आलोचना करते हैं, यह कहते हुए कि CommonJS सरल था और “काफ़ी अच्छा” था; दूसरे जवाब देते हैं कि declarative ESM बेहतर optimization और browser-native modules सक्षम करता है।

विकल्प: Deno और Bun

  • Deno को “बस काम करता है” TypeScript, built-in tooling, और security के लिए सराहा जाता है, लेकिन ecosystem compatibility (खासकर npm के साथ) और कुछ quirks बने हुए हैं।
  • Bun को ESM/CJS मुद्दों को जादुई तरीके से smooth out करने और शानदार DX देने वाला माना जाता है, लेकिन यह भी बहुत नया और अभी भी buggy है; कई लोग production में इसे इस्तेमाल करने को लेकर सतर्क हैं।