TypeScript 6.0 की घोषणा

• JavaScript-आधारित मौजूदा codebase की अंतिम release, और Go में लिखे गए native port TypeScript 7.0 में ट्रांज़िशन की तैयारी करने वाली bridge release
• this का उपयोग न करने वाले functions की context sensitivity में ढील, #/ से शुरू होने वाले subpath imports का समर्थन आदि सहित type inference और module resolution में सुधार
• strict का default true, target का default es2025, types का default [] आदि के साथ compiler option defaults का बड़ा आधुनिकीकरण
• ES5 target, AMD/UMD/SystemJS modules, --baseUrl, --moduleResolution node10 आदि जैसे legacy options का बड़े पैमाने पर deprecation
• Temporal API, Map के getOrInsert/getOrInsertComputed, RegExp.escape आदि जैसे नवीनतम ECMAScript Stage 4 proposals के लिए type support जोड़ा गया

---

TypeScript 6.0 की स्थिति

• मौजूदा JavaScript codebase पर आधारित अंतिम release, जो TypeScript 7.0 (Go native port) की ओर संक्रमण के लिए bridge की भूमिका निभाती है
• TypeScript 7.0 native code और shared-memory multithreading का उपयोग करता है, और पहले से ही लगभग पूर्णता के करीब है
• 6.0 के अधिकांश बदलाव 7.0 को अपनाने के लिए alignment और तैयारी पर केंद्रित हैं
• TypeScript 7.0 को VS Code extension या npm package के ज़रिए पहले से आज़माया जा सकता है

Beta और RC के बाद के बदलाव

• generic calls (खासकर generic JSX expressions) में function expressions की type checking में समायोजन — इससे मौजूदा code में अधिक bugs पकड़े जा सकते हैं, लेकिन कुछ generic calls में explicit type arguments की ज़रूरत पड़ सकती है
• import() calls में भी import assertion syntax (assert) के deprecation का विस्तार लागू
• DOM types update — नवीनतम web standards को दर्शाता है, जिसमें Temporal API से जुड़े समायोजन शामिल हैं

this का उपयोग न करने वाले functions की context sensitivity में ढील

• TypeScript, type inference के दौरान बिना explicit type वाले parameters रखने वाले functions को contextually sensitive function के रूप में वर्गीकृत करता है, और उन्हें inference क्रम में बाद में प्रोसेस करता है
• method syntax में लिखे गए functions में implicit this parameter होता है, इसलिए उन्हें arrow functions के विपरीत हमेशा context sensitive माना जाता था
  • इससे object literal के अंदर methods के क्रम के आधार पर type inference fail होने की स्थिति बनती थी
• TypeScript 6.0 में वे functions जिनमें this वास्तव में उपयोग नहीं होता अब context sensitive नहीं माने जाते
  • ऐसे functions को type inference में उच्च प्राथमिकता मिलती है, जिससे method order की परवाह किए बिना सही inference होता है
• Mateusz Burzyński के contribution से लागू

#/ से शुरू होने वाले Subpath Imports का समर्थन

• Node.js की subpath imports सुविधा package के भीतर modules के aliases को package.json के imports field में define करती है
• पहले # के बाद अनिवार्य रूप से कोई character होना चाहिए था, इसलिए #/ से शुरू होने वाले paths का उपयोग संभव नहीं था
  • इससे bundler में @/ prefix convention के अभ्यस्त developers के लिए भ्रम पैदा होता था
• Node.js ने हाल ही में #/ से शुरू होने वाले subpath imports को support करना शुरू किया
  • "#/*": "./dist/*" जैसे concise mappings संभव
• TypeScript 6.0 इसे --moduleResolution nodenext और bundler options में support करता है
• magic-akari के contribution से लागू

--moduleResolution bundler और --module commonjs का संयोजन अनुमत

• पहले --moduleResolution bundler केवल --module esnext या --module preserve के साथ ही इस्तेमाल किया जा सकता था
• --moduleResolution node(node10) के deprecation के कारण, यह नया combination कई projects के लिए सबसे उपयुक्त upgrade path है
• लंबी अवधि में --module preserve + --moduleResolution bundler या --module nodenext की ओर migration की सिफारिश

--stableTypeOrdering flag

• TypeScript के भीतर types को दिए जाने वाले type IDs processing order के आधार पर तय होते हैं, और union types की sorting इसी पर आधारित होती है
  • declaration order के अनुसार declaration emit results बदलने जैसी अप्रत्याशित स्थिति बन सकती है
• TypeScript 7.0 parallel type checking लाता है, इसलिए non-deterministic ID assignment की समस्या हल करने के लिए content-based deterministic sorting algorithm का उपयोग करता है
  • उदाहरण: 100 | 500 हमेशा एक ही क्रम में output होगा
• 6.0 में --stableTypeOrdering flag सक्षम करने पर इसे 7.0 के type ordering behavior से match कराया जा सकता है, जिससे दोनों codebases के बीच का अंतर कम होगा
  • type checking में अधिकतम 25% performance drop हो सकता है
  • inference differences से type errors आएँ तो explicit type arguments या variable annotations जोड़कर समाधान किया जा सकता है
• यह flag केवल 6.0 से 7.0 migration diagnosis के लिए है, लंबे समय तक उपयोग की सिफारिश नहीं

es2025 option (target और lib)

• ES2025 में नए JavaScript language features नहीं हैं, लेकिन built-in API types (जैसे RegExp.escape) जोड़े गए हैं
• esnext में मौजूद Promise.try, Iterator methods, Set methods आदि es2025 में शिफ्ट किए गए
• Kenta Moriuchi के contribution से लागू

Temporal API type support

• Stage 4 तक पहुँच चुके Temporal proposal के built-in types को TypeScript 6.0 में शामिल किया गया
• --target esnext या "lib": ["esnext"] (या granular esnext.temporal) के साथ इस्तेमाल किया जा सकता है
• Temporal.Now.instant().subtract(), .add() जैसी APIs को type-safe तरीके से इस्तेमाल किया जा सकता है
• यह कई runtimes में पहले से उपलब्ध है और Stage 4 के साथ आधिकारिक JavaScript language का हिस्सा बन चुका है
• Renegade334 के contribution से लागू

Map के "upsert" methods के लिए type support (getOrInsert / getOrInsertComputed)

• Map में key की मौजूदगी जाँचने और न होने पर default value सेट करने वाले दोहराए जाने वाले pattern को सरल बनाता है
• ECMAScript का "upsert" proposal Stage 4 तक पहुँच चुका है, और Map तथा WeakMap में दो नए methods जोड़ता है
  • getOrInsert: key न होने पर दी गई default value insert करके return करता है
  • getOrInsertComputed: जब default value बनाना महँगा हो, तब callback के ज़रिए lazy calculation करता है
    • callback key को argument के रूप में लेता है, इसलिए key-आधारित default value generation में भी उपयोगी है
• esnext lib में जोड़ा गया है और TypeScript 6.0 में तुरंत इस्तेमाल किया जा सकता है
• Renegade334 के contribution से लागू

RegExp.escape

• regular expressions के भीतर special characters को escape करने वाला RegExp.escape function Stage 4 तक पहुँच चुका है
• es2025 lib में शामिल है और TypeScript 6.0 में उपलब्ध है
• Kenta Moriuchi के contribution से लागू

dom lib में dom.iterable और dom.asynciterable का एकीकरण

• पहले NodeList, HTMLCollection आदि पर iteration इस्तेमाल करने के लिए "lib": ["dom", "dom.iterable"] को explicit रूप से लिखना पड़ता था
• TypeScript 6.0 में lib.dom.iterable.d.ts और lib.dom.asynciterable.d.ts की सामग्री पूरी तरह lib.dom.d.ts में merge कर दी गई है
  • dom.iterable, dom.asynciterable अब भी refer किए जा सकते हैं, लेकिन वे empty files हैं
• चूँकि सभी प्रमुख आधुनिक browsers इस सुविधा का समर्थन करते हैं, यह आम भ्रम को हटाने वाला convenience improvement है

प्रमुख default changes

• strict default true: अधिकांश नए projects strict mode चाहते हैं, इसलिए जो projects पहले के false behavior पर निर्भर थे उन्हें explicit "strict": false सेट करना होगा
• module default esnext: यह दर्शाता है कि ESM अब प्रमुख module format बन चुका है
• target default नवीनतम ES version (वर्तमान में es2025): evergreen runtimes के सामान्य होने से पुराने versions के लिए transpile करना अब कम ज़रूरी है
• noUncheckedSideEffectImports default true: side-effect-only imports में typos पकड़ने में मदद
• libReplacement default false: अनावश्यक module resolution failures और watched targets बढ़ने से बचाकर default performance बेहतर करता है

rootDir default बदलकर .

• पहले अगर यह specify न हो तो सभी non-declaration input files की common directory infer करके तय की जाती थी
  • इससे यह तय करने के लिए कि कोई file project की है या नहीं, उस project को load और parse करना पड़ता था
• TypeScript 6.0 में default अब वह directory है जहाँ tsconfig.json मौजूद है
• अगर source files tsconfig.json से और गहराई में हों, तो "rootDir": "./src" जैसी explicit setting देनी होगी
  • अन्यथा ./dist/src/index.js जैसी अनचाही output structure बन सकती है

types default बदलकर []

• पहले node_modules/@types के भीतर सभी packages अपने आप शामिल हो जाते थे, जिससे build time में बड़ा overhead आता था
  • सामान्य repositories में सैकड़ों @types packages transitively शामिल हो जाते थे
• TypeScript 6.0 में default [] (empty array) कर दिया गया, ताकि अनावश्यक declaration files load न हों
• वास्तविक build time में 20~50% सुधार के उदाहरण देखे गए
• अधिकांश projects में "types": ["node"] या "types": ["node", "jest"] जैसी explicit settings की ज़रूरत होगी
  • "types": ["*"] से पुराना behavior बहाल किया जा सकता है

Deprecation items

target: es5 deprecation

• ES5 target का उपयोग लगभग समाप्त हो चुका है क्योंकि IE रिटायर हो चुका है और evergreen browsers आम हो गए हैं
• minimum target अब ES2015 है; अगर ES5 output चाहिए तो external compiler के उपयोग की सिफारिश

--downlevelIteration deprecation

• इसका प्रभाव केवल ES5 emit में था, इसलिए ES5 target deprecation के साथ इसका उद्देश्य भी समाप्त

--moduleResolution node(node10) deprecation

• यह Node.js 10 के module resolution algorithm को दर्शाता था, जो आधुनिक Node.js behavior से मेल नहीं खाता
• nodenext (सीधे Node.js target करने के लिए) या bundler (bundlers/Bun के लिए) में migration की सिफारिश

AMD, UMD, SystemJS module values deprecation

• --module amd, --module umd, --module systemjs, --module none अब supported नहीं हैं
• चूँकि ESM browsers और Node.js दोनों में व्यापक रूप से supported है, bundler या ESM target की ओर जाना आवश्यक है

--baseUrl deprecation

• इसे मुख्यतः paths के prefix के रूप में इस्तेमाल किया जाता था, लेकिन यह module resolution के lookup root की तरह भी काम करता था, जिससे अनचाहे path resolution issues पैदा होते थे
• baseUrl हटाकर paths entries में सीधे prefix जोड़कर migration किया जा सकता है
  • उदाहरण: "@app/*": ["app/*"] → "@app/*": ["./src/app/*"]

--moduleResolution classic deprecation

• यह TypeScript का मूल module resolution algorithm था, लेकिन अब लगभग सभी व्यावहारिक मामलों में nodenext या bundler इसे replace कर सकते हैं

esModuleInterop false और allowSyntheticDefaultImports false deprecation

• इन दोनों options को false पर सेट करना अब संभव नहीं होगा, यानी safe interop behavior हमेशा enabled रहेगा
• import * as express from "express" → import express from "express" जैसी adjustment की ज़रूरत पड़ सकती है

--alwaysStrict false deprecation

• अब सभी code को JavaScript strict mode में माना जाएगा, इसलिए await, static, private आदि को सामान्य identifiers की तरह इस्तेमाल करने वाले code में नाम बदलने होंगे

outFile deprecation

• यह कई input files को एक में combine करने की सुविधा थी, लेकिन अब Webpack, Rollup, esbuild, Vite जैसे external bundlers इसका स्थान ले चुके हैं
• यह निर्णय TypeScript की मूल भूमिका, यानी type checking और declaration emit, पर फोकस बनाए रखने के लिए लिया गया है

legacy module syntax (namespace declarations) deprecation

• module Foo { ... } syntax hard deprecated है; अब namespace Foo { ... } का उपयोग करना होगा
• declare module "some-module" { ... } जैसे ambient module declarations अब भी supported हैं
• उद्देश्य ECMAScript के module block proposal के साथ टकराव से बचना है

Import asserts keyword deprecation

• import ... asserts { type: "json" } → import ... with { type: "json" } में बदलाव करना होगा
• यह import assertions proposal के import attributes proposal (with keyword) में बदलने के कारण किया गया है

no-default-lib directive deprecation

• /// <reference no-default-lib="true"/> अब supported नहीं है; --noLib या --libReplacement के उपयोग की सिफारिश

tsconfig.json मौजूद होने पर command-line file specification error

• tsc foo.ts चलाने पर यदि उसी directory में tsconfig.json हो, तो error होगी
• इसे explicit रूप से ignore करने के लिए --ignoreConfig flag उपलब्ध है

TypeScript 7.0 की तैयारी

• 6.0 में deprecated options को "ignoreDeprecations": "6.0" setting के साथ बिना error जारी रखा जा सकता है, लेकिन 7.0 में वे पूरी तरह हटा दिए जाएँगे
• ts5to6 tool के ज़रिए baseUrl, rootDir आदि का auto-adjustment संभव है
• TypeScript 7.0 के कुछ महीनों में release होने की उम्मीद है, और Microsoft के भीतर तथा बाहर के बड़े codebases में इसे पहले से व्यापक रूप से अपनाया जा रहा है
• native preview nightly build और VS Code extension के ज़रिए feedback देने की सिफारिश

[tsboard]

Go-आधारित compiler पर पूरी तरह स्विच होने का समय आने का इंतज़ार है!

[princox]

अरे? क्या TypeScript बाद में Go-आधारित native में बदल जाएगा?

[helio]

सिर्फ compiler