TypeScript 7.0 की घोषणा

(devblogs.microsoft.com)

4 पॉइंट द्वारा GN⁺ 2 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें

TypeScript 7.0 एक ऐसा रिलीज़ है जिसमें toolchain को Go-आधारित native code में port किया गया है, और यह बड़े projects के full build में आम तौर पर 8–12 गुना speed improvement देता है
नया tsc पहले की तरह npm के typescript package से install होता है, और editor support LSP-आधारित language server के ज़रिए VS Code, Visual Studio, WebStorm आदि में काम करता है
vscode, sentry, bluesky, playwright, tldraw जैसे codebase में build time काफी घटा, और कुछ environments में कुल memory usage भी कम हुआ
TypeScript 7.0 में अभी stable programming API नहीं है, इसलिए typescript-eslint, Vue, MDX, Astro, Svelte, Angular template type checking जैसे TypeScript को embed करने वाले tools के लिए TypeScript 6.0 को साथ-साथ चलाना ज़रूरी है
नए defaults और हटाए गए options हैं, इसलिए transition के लिए TypeScript 6.0 के changes पहले apply करना बेहतर है, और TypeScript 7.1 में नई API उपलब्ध कराने की योजना है

Go-आधारित native TypeScript

TypeScript 7.0 TypeScript toolchain का native port है, जो Go में लिखे नए codebase का उपयोग करता है
इसे इस तरह port किया गया है कि पुराने codebase की structure और logic को जितना हो सके बनाए रखते हुए दोनों compilers के results की consistency और compatibility मिलाई जा सके
नया codebase native code speed, shared memory-based multithreading, और कई optimizations के ज़रिए full build में आम तौर पर 8–12 गुना तेज़ नतीजे देता है
installation पहले की तरह npm से की जा सकती है

npm install -D typescript

install करने के बाद workspace में नया tsc executable इस्तेमाल किया जा सकता है, और इसे npx tsc से चलाया जा सकता है

development feedback loop को छोटा करना

TypeScript editor loading, find all references, autocomplete, diagnostics, tsc, --watch mode जैसे development process के कई चरणों में शामिल होता है
TypeScript 7 इस पूरी process में wait time घटाकर feedback loop को छोटा बनाता है
VS Code codebase में error वाली file खोलने पर पहला error दिखने में लगने वाला समय लगभग 17.5 सेकंड से घटकर 1.3 सेकंड से कम हो गया, यानी 13 गुना से अधिक तेज़
editor support LSP-आधारित है, और नया language server multithreading का उपयोग करके concurrent requests को तेज़ी से handle करता है
VS Code users TypeScript 7 dedicated extension install कर सकते हैं, और आने वाले कुछ हफ्तों में VS Code में भी TypeScript 7 support शामिल होने की योजना है
Visual Studio का latest version workspace के आधार पर TypeScript 7 को automatically activate करता है

build performance और memory results

बड़े open source codebase में TypeScript 6 और 7 की तुलना में full build time इस प्रकार है

codebase	TypeScript 6	TypeScript 7	speed improvement
vscode	125.7 सेकंड	10.6 सेकंड	11.9 गुना
sentry	139.8 सेकंड	15.7 सेकंड	8.9 गुना
bluesky	24.3 सेकंड	2.8 सेकंड	8.7 गुना
playwright	12.8 सेकंड	1.47 सेकंड	8.7 गुना
tldraw	11.2 सेकंड	1.46 सेकंड	7.7 गुना

उसी build में TypeScript 7 ने आम तौर पर कुल memory usage भी कम दिखाया

codebase	TypeScript 6	TypeScript 7	memory change
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

real codebase validation और team feedback

TypeScript project 10 साल से अधिक समय में जमा हुए दसियों हज़ार tests हर main branch commit पर चलाता है
इन tests के अलावा TypeScript 7 को internal और external बड़ी teams के real codebase में भी validate किया गया
Microsoft के अंदर Loop, Office, PowerBI, Teams, Xbox teams ने TypeScript 7 को validate किया
बाहर Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero आदि ने अपने codebase में test करके feedback दिया
नए language server ने TypeScript 6.0 की तुलना में failed language server commands को 80% से अधिक, और server crashes को 60% से अधिक घटाया
वास्तविक team feedback में ये cases शामिल हैं
- Slack ने बताया कि TypeScript 7 से merge queue time 40% घटा, और CI type checking time लगभग 7.5 मिनट से 1.25 मिनट हो गया
- Vanta ने अपने एक बड़े project में maximum 9 गुना build speed improvement देखा
- Microsoft News Services team ने CI build wait time में प्रति माह 400 घंटे बचाए
- Canva ने बताया कि editor में पहला error दिखने में लगने वाला समय लगभग 58 सेकंड से 4.8 सेकंड हो गया

TypeScript 6.0 के साथ parallel execution

TypeScript 7.0 में अभी API शामिल नहीं है
TypeScript 7.1 में नई और अलग API देने की योजना है
तब तक compiler तक programming access की ज़रूरत वाले tools के लिए TypeScript 6.0 और 7.0 को साथ-साथ चलाया जा सकता है
नया compatibility package @typescript/typescript6 tsc6 executable देता है और TypeScript 6.0 API को फिर से export करता है
typescript-eslint जैसे tools, जो peer dependency के रूप में सीधे typescript import करते हैं, उनके लिए npm alias इस्तेमाल करने की सलाह है

npm install -D typescript@npm:@typescript/typescript6

TypeScript 6 API और TypeScript 7 के tsc को साथ इस्तेमाल करने के लिए इस तरह alias रखा जा सकता है

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

मौजूदा @typescript/native-preview package TypeScript 7 के नए codebase के nightly builds देता रहा है, और इसके weekly downloads 85 लाख से अधिक थे
आगे nightly builds standard typescript package के next tag से फिर शुरू किए जाने की योजना है

npm install -D typescript@next

parallelization control options

TypeScript 7.0 parsing, type checking, emit जैसे कई चरणों को parallel में execute करता है
parsing और emit को file-by-file independently चलाना आसान है, इसलिए बड़े codebase में ये relatively कम overhead के साथ scale होते हैं
नए experimental flags --checkers, --builders, --singleThreaded parallelization behavior को adjust करते हैं

`--checkers`

TypeScript 7.0 fixed number of type checking workers बनाता है, और समान input files के लिए हमेशा काम को समान तरीके से बांटता है ताकि identical results मिलें
default type checking workers की संख्या 4 है, और इसे --checkers से adjust किया जा सकता है
उसी machine पर --checkers 8 इस्तेमाल करने के results इस प्रकार हैं

codebase	TypeScript 6	TypeScript 7 `--checkers 8`	speed improvement
vscode	125.7 सेकंड	7.51 सेकंड	16.7 गुना
sentry	139.8 सेकंड	12.08 सेकंड	11.6 गुना
bluesky	24.3 सेकंड	2.01 सेकंड	12.1 गुना
playwright	12.8 सेकंड	1.16 सेकंड	11 गुना
tldraw	11.2 सेकंड	1.06 सेकंड	10.6 गुना

--checkers बढ़ाने पर ज्यादा CPU cores का उपयोग करके build तेज हो सकता है, लेकिन आम तौर पर इसके साथ memory usage बढ़ना भी आता है
- कम CPU cores और memory वाले CI runner में value कम रखकर अनावश्यक overhead से बचा जा सकता है
- --checkers 1 type checking को व्यावहारिक रूप से single-threaded बना देता है और duplicate काम हटाता है
- दुर्लभ मामलों में --checkers की संख्या में बदलाव order-dependent results को उजागर कर सकता है, इसलिए पूरे build environment में fixed checker count तय करना मददगार हो सकता है
--builders
- --builders, --build चलाते समय एक साथ चल सकने वाले project reference builders की संख्या नियंत्रित करता है
- बहुत सारे projects वाले monorepo में यह खास तौर पर मददगार हो सकता है
- value बढ़ाने से build तेज हो सकता है, लेकिन memory usage भी बढ़ सकता है
- --checkers के साथ इसका multiplication effect होता है, इसलिए --checkers 4 --builders 4 में अधिकतम 16 type checkers एक साथ चल सकते हैं
- --builders की संख्या में बदलाव, --checkers के विपरीत, अलग results नहीं बनाने चाहिए
- project reference build में मूल रूप से project dependency graph के कारण bottleneck बनता है
--singleThreaded
- --singleThreaded पूरे compiler को single thread में चलाने के लिए मजबूर करता है
- यह debugging, TypeScript 6 और 7 की performance तुलना, external parallel build orchestration, और बहुत सीमित resources वाले environments में उपयोगी हो सकता है
- यह flag type checking workers की संख्या को 1 तक सीमित करने के साथ-साथ parsing और emit को भी single thread में कराता है

नया `--watch` mode

TypeScript 7 ने --watch mode को पूरी तरह से फिर से बनाया है
नया --watch, Parcel bundler के file-watcher पर आधारित efficient और stable cross-platform file watching सुविधा देता है
Go standard library में built-in file watching API नहीं है, और जिन third-party libraries की समीक्षा की गई उनमें stability, performance, cross-platform support, और build tools integration से जुड़ी समस्याएं थीं
pure polling तरीका कई operating systems पर काम करता था, लेकिन node_modules dependencies ज्यादा होने वाले बड़े projects में इसकी computational cost अधिक थी
TypeScript team ने VS Code में इस्तेमाल होते आए @parcel/watcher को Go में port किया, और C++ toolchain dependency से बचने के लिए minimal assembly shim का उपयोग किया
यह watcher एक independent package है, और TypeScript 7 के --watch mode में platforms के across resource usage improvements लाता है

TypeScript 6.0 defaults और compatibility changes

TypeScript 7.0 को TypeScript 6.0 की type checking और command-line behavior के साथ compatible बनाया गया है
stableTypeOrdering flag on हो और ignoreDeprecations set न हो, ऐसी स्थिति में TypeScript 6.0 से cleanly compile होने वाला code TypeScript 7.0 में भी उसी तरह compile होना चाहिए
TypeScript 7.0, TypeScript 6.0 के नए defaults अपनाता है, और TypeScript 6.0 में deprecated flags और syntax पर hard error देता है
मुख्य configuration defaults में बदलाव ये हैं
- strict default true है
- module default esnext है
- target default, esnext से ठीक पहले की current stable ECMAScript version है
- noUncheckedSideEffectImports default true है
- libReplacement default false है
- stableTypeOrdering default true है और इसे बंद नहीं किया जा सकता
- rootDir default ./ है
- types default [] है, और पहले वाला behavior ["*"] से restore किया जा सकता है
rootDir और types में बदलाव सबसे ज्यादा चौंकाने वाले changes माने जा सकते हैं
- जिन projects में tsconfig.json, src जैसी source directory के बाहर है, उन्हें मौजूदा directory structure बनाए रखने के लिए rootDir explicitly set करना होगा
- specific global declarations पर निर्भर projects को जरूरी @types packages को types में explicitly लिखना होगा

{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

हटाए गए या hard error बने behaviors

TypeScript 7.0 में TypeScript 6.0 में deprecated कई options और syntax अब supported नहीं हैं
मुख्य items इस प्रकार हैं
- target: es5 supported नहीं
- downlevelIteration supported नहीं
- moduleResolution: node/node10 supported नहीं, nodenext और bundler recommended हैं
- module: amd, umd, systemjs, none supported नहीं, bundler या browser-based module resolution के साथ esnext या preserve recommended हैं
- baseUrl supported नहीं, paths को baseUrl के बजाय project root के relative paths के आधार पर update किया जा सकता है
- moduleResolution: classic supported नहीं, bundler या nodenext recommended हैं
- esModuleInterop और allowSyntheticDefaultImports को false पर set नहीं किया जा सकता
- alwaysStrict को true माना जाता है और इसे false पर set नहीं किया जा सकता
- namespace declarations में module keyword का उपयोग नहीं किया जा सकता
- import में asserts keyword का उपयोग नहीं किया जा सकता; ECMAScript import attribute syntax बदलाव के अनुसार with का उपयोग करना होगा
- skipDefaultLibCheck के तहत /// <reference no-default-lib /> directive का अब सम्मान नहीं किया जाता
- अगर current directory में tsconfig.json है, तो command-line build में file paths नहीं लिए जा सकते, और explicit --ignoreConfig जरूरी है

template literal types और JavaScript support changes

TypeScript 7.0, template literal type inference में Unicode code point को ज्यादा natural तरीके से handle करता है

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// 이전: ["\ud83d", "\ude00abc"]

पहले JavaScript के UTF-16 indexing behavior का पालन करते हुए "😀" को surrogate pair के दो हिस्सों में बांटा जाता था
नया behavior for...of या [...str] की तरह "😀" को एक unit मानने वाली intuition से मेल खाता है
UTF-16 code unit को जानबूझकर model करने वाले type-level string manipulation के लिए यह breaking change हो सकता है
JavaScript support को TypeScript files के analysis तरीके के साथ अधिक consistent बनाने के लिए reworked किया गया है
- type positions में values का उपयोग नहीं किया जा सकता और typeof someValue लिखना होगा
- @enum को अब special treatment नहीं मिलता
- अकेला ? type के रूप में इस्तेमाल नहीं किया जा सकता और any लिखना होगा
- @class function को constructor नहीं बनाता; class declaration लिखना होगा
- postfix ! supported नहीं है
- type names को @typedef tag के अंदर define करना होगा
- Closure-style function syntax अब supported नहीं है और TypeScript shorthand syntax का उपयोग करना होगा
this aliasing और function prototype की पूरी reassignment जैसे कुछ JavaScript patterns को भी अब special treatment नहीं मिलता
TypeScript 6.0 और 7.0 के differences को CHANGES.md में और विस्तार सेまとめा जा रहा है

एडिटर फीचर्स और सीमाएं

TypeScript 7.0 में beta के बाद गायब रहे कई editor फीचर्स जोड़े गए हैं
इनमें auto import, expandable hover, inlay hint, code lens, go-to-source-definition, JSX linked editing, tag completion आदि शामिल हैं
semantic highlighting, “sort imports”, “remove unused imports” जैसे TypeScript 7.0 beta में छूटे फीचर्स भी शामिल किए गए हैं
language server की गुणवत्ता के लिए testing और diagnostics infrastructure को फिर से बनाया गया है, और GitHub के प्रमुख TypeScript·JavaScript codebases पर fuzz test किए जा सकते हैं

embedded language workflow की मौजूदा सीमाएं

Vue, MDX, Astro, Svelte आदि इस्तेमाल करने वाले workflows के अभी TypeScript 7 का लाभ न उठा पाने की संभावना अधिक है
Angular templates जैसे special template type checking के भी TypeScript 7 का उपयोग न कर पाने की संभावना अधिक है
मुख्य वजह यह है कि TypeScript 7 अभी stable programming API expose नहीं करता
Volar जैसे tools, जो TypeScript को अपने compiler और language service में embed करते हैं, फिलहाल TypeScript 6.0 पर निर्भर रहने को मजबूर हैं
TypeScript team इसे किसी खास समय की limitation के रूप में देखती है, और इन project maintainers के साथ मिलकर TypeScript 7 support सुनिश्चित करने की योजना रखती है
तब तक, उन scenarios में TypeScript 7 इस्तेमाल करने की सलाह है जहां language server plugin की जरूरत नहीं होती
Angular projects CLI में तेज project-wide error detection के लिए TypeScript 7 का tsc इस्तेमाल कर सकते हैं, और editor support के लिए साथ में TypeScript 6.0 का उपयोग कर सकते हैं
Vue, MDX, Astro, Svelte आदि को फिलहाल TypeScript 6.0 का उपयोग जारी रखना होगा
VS Code में “Disable TypeScript 7 Language Server” command से TypeScript 6.0 पर वापस लौटा जा सकता है

आगे की योजना

TypeScript 7.0 release, TypeScript project में एक साल से अधिक समय से focus रहे native port का अहम milestone है
7.0 के बाद, नई features पर काम, usability सुधार, अतिरिक्त performance improvements, और ecosystem के लिए नए API implementation पर वापस जाने की योजना है
TypeScript 7.0 से पहले की तरह हर 3~4 महीने में new feature release आने की उम्मीद है
TypeScript 7.1 में community transition में मदद के लिए gaps को भरना और नए API उपलब्ध कराना planned है

2 टिप्पणियां

GN⁺ 2 시간 전

Hacker News की टिप्पणियाँ

उनके अपने टेस्ट के अनुसार TypeScript 7 की speed improvement इस प्रकार है

Codebase TypeScript 6 TypeScript 7 Speedup

vscode 125.7s 10.6s 11.9x

sentry 139.8s 15.7s 8.9x

bluesky 24.3s 2.8s 8.7x

playwright 12.8s 1.47s 8.7x

tldraw 11.2s 1.46s 7.7x

ज़िम्मेदारी से migration करते हुए इस स्तर का परिणाम हासिल करने वाली टीम वाकई शानदार है। अच्छा होता अगर Bun भी इससे कुछ सीखता। जिज्ञासा यह है कि tsdown या esbuild जैसे नीचे के tools, जिन्हें TypeScript codebase build करना पड़ता है, उन पर इसका क्या असर होगा, और क्या TS 7 को मौजूदा tsdown के साथ इस्तेमाल किया जा सकता है
- esbuild TypeScript पर बिल्कुल depend नहीं करता, इसलिए कोई समस्या नहीं है। tsdown में यह --isolatedDeclarations के उपयोग पर निर्भर करता है, और अगर ऐसा नहीं है तो ब्लॉग के निर्देश के अनुसार TypeScript 6 को साथ में install कर सकते हैं
- क्या आपका मतलब है कि Bun का migration गैर-ज़िम्मेदाराना था?
एक समय ऐसा भी था जब लोग बहस करते थे कि types पर लगने वाली मेहनत उसकी वैल्यू के लायक नहीं है। TypeScript की सबसे बड़ी खूबी यह है कि उसने types को mainstream बनाया
- types से नफ़रत करने वाले लोग मुझे ज़्यादा याद नहीं हैं। बहुत से लोग जिस चीज़ को नापसंद करते थे, वह static typing थी, और अधिक सटीक रूप से static और explicit typing
  उदाहरण के लिए, मैंने कई बार यह सुना है कि Python को इसलिए इस्तेमाल नहीं किया जा सकता क्योंकि उसमें types नहीं हैं, लेकिन यह बात सही नहीं है। Python एक strongly typed language है, और साथ ही एक dynamically typed language भी है।
  कुछ भाषाएँ सच में ऐसी भी हैं जिनमें types नहीं होते, या जिन्हें आम तौर पर “stringly typed” कहा जाता है। बचपन में मैंने AREXX के साथ काम किया था, जहाँ हर value string होती थी, चाहे वह संख्या जैसी दिखे, और sed जैसे ज़्यादातर Unix CLI tools को भी इसी तरह देखा जा सकता है। लेकिन types पर होने वाली ज़्यादातर बहस Python जैसी dynamic typing वाली भाषाओं के इर्द-गिर्द ही थी, और बड़े projects के लिए weakly typed या untyped language बेहतर हैं, ऐसा कहते हुए लोग शायद ही कभी दिखे। उल्टा, Python को ग़लती से “type-less” कहकर बड़े projects के लिए अनुपयुक्त बताने वाली बातें बहुत सुनीं, और जब आप खुद Python में बड़े projects बना रहे हों तो यह काफ़ी उलझन भरा लगता है
- पुराने type systems बस अच्छे नहीं थे। sum types जैसे “OR” types को व्यक्त करने के लिए class hierarchy थोपना बहुत पीड़ादायक है। TypeScript, Rust, Swift, Kotlin जैसी आधुनिक भाषाएँ, जिनमें sum types हैं, कहीं ज़्यादा सहज लगती हैं
- मैंने व्यक्तिगत रूप से लगभग शब्दशः “मुझे JavaScript में कभी typing error का सामना नहीं करना पड़ा” कहने वाले तीन लोगों से बात की है। उनमें से दो ऐसे लोग थे जिनके काम का मैं सम्मान करता था, इसलिए यह समझना मुश्किल था कि वे ऐसा दृष्टिकोण कैसे रख सकते हैं
- मुझे लगता है algebraic data types और pattern matching ने पूरा खेल बदल दिया। Haskell जितना आगे जाए बिना भी types अचानक बहुत ज़्यादा उपयोगी हो गए
  पहले types के साथ ज़्यादातर exposure C++/Java के माध्यम से था, और खासकर C++ किसी चीज़ का अच्छा उदाहरण कम, बल्कि ज़रूरत से ज़्यादा जटिल भाषा बनाने का उदाहरण ज़्यादा था। जब कोई एक बार types के अच्छे उपयोग को देख लेता है, तो उसे समझाना कहीं आसान हो जाता है
- अब बस DependentTypeScript का इंतज़ार है
यहाँ सच में प्रभावशाली बात यह है कि मानवता के ज्ञात सबसे उन्नत type system के लिए दो अलग codebases को एक साथ maintain करने वाली यह बेहतरीन टीम। Rust rewrite का भी इंतज़ार है
- मुझे नहीं पता कि Rust rewrite वाकई मायने रखेगा या नहीं। Go में coding तेज़ होती है, और code को देखकर TypeScript का 1:1 पुनः-implementation करना आसान है
  Rust में development time काफ़ी ज़्यादा लगेगा। Rust, Go से 20% तेज़ हो सकता है, लेकिन TypeScript से Go में जो improvement मिली है, वही अपने आप में काफ़ी बड़ी है। vscode में Go से 11x की बजाय Rust से शायद 14x मिले, लेकिन Go ही इतना फ़र्क पैदा करने के लिए पर्याप्त है
- इसे सबसे जटिल तो कहा जा सकता है, लेकिन “सबसे उन्नत” type system कहना ठीक है या नहीं, यह निश्चित नहीं। उस ख़िताब का कोई अंतिम जवाब नहीं है, लेकिन proof assistant languages में से कोई एक शायद ज़्यादा मज़बूत दावेदार हो सकती है
  मेरा उद्देश्य TypeScript के type system को कमतर दिखाना नहीं है; वास्तव में यह बेहद दिलचस्प काम है
- Hugo और कई बड़े Go projects बनाने वाले Steve Francia ने agent era के Go पर एक लेख लिखा है: https://spf13.com/p/go-the-agentic-language/
- “मानवता के ज्ञात सबसे उन्नत type system” से आपका ठीक-ठीक क्या मतलब है?
- मेरी समझ में Rust आदि पर भी गंभीरता से विचार किया गया था, और उसके बाद Go को चुना गया। सारे कारण याद नहीं हैं, लेकिन मूल ब्लॉग पोस्ट में यह विस्तार से लिखा था
कुछ साल TypeScript इस्तेमाल करने के बाद, Python में type annotations हाथ से लिखना और abc जैसी बुनियादी language features को लाना सच में बहुत झंझट भरा लगता है
दिलचस्प है, लेकिन अब Node native रूप से TypeScript type annotations को strip कर देता है, इसलिए मैं लगभग कभी TSC नहीं चलाता। बस तब चलाता हूँ जब कोई बड़ा regression change बना हो और compiler के static output से यह देखना हो कि कौन-कौन सी चीज़ें update नहीं हुईं
browser में जाने वाले frontend code के लिए भी मैं Node की type stripping पर निर्भर करता हूँ
- यह सही है, लेकिन दूसरी तरफ editor पूरे दिन TypeScript language server चला रहा होता है। शायद CI भी, और AI agents भी, इससे पहले कि वे अभी किए गए काम पर भरोसा करें
अच्छा लगता है कि JSDoc type syntax पर लगातार ध्यान दिया जा रहा है। personal projects में TypeScript इस्तेमाल करने का यह मेरा पसंदीदा तरीका है। कुछ syntax changes को update करना झंझट भरा हो सकता है, लेकिन ज़्यादातर बदलाव बेहतर दिशा में लगते हैं
- शुक्र है कि TypeScript, Microsoft की दूसरी भाषाओं में इस्तेमाल होने वाले भयानक XML format की बजाय JSDoc का उपयोग करता है
  [1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
TypeScript की बड़ी परेशानियों में से एक यह है कि प्रोजेक्ट के कुछ हिस्सों के लिए lib और types जैसी tsconfig setting scope को समायोजित करना मुश्किल है
प्रोजेक्ट वेबऐप है, लेकिन vite.config.ts, Playwright और unit test की वजह से IDE tooling की तरफ Node types आ जाते हैं। React component में Node API जोड़ दें तो भी tsc शिकायत नहीं करता।
अभी DOM library और Node library को अलग-थलग करने के लिए project reference spaghetti, ढेर सारे tsconfig.json और tsbuildinfo output files चाहिए, और project reference इस्तेमाल करते हुए type output से बचना भी झंझट है
- इस वाकई दर्दनाक हिस्से से सहमत हूँ। nx इस्तेमाल कर रहा हूँ, और यह ऐसी चीज़ें संभाल देता है। Playwright अपनी tsconfig वाला अलग प्रोजेक्ट है, और सब root tsconfig inherit करते हैं
  एक single application में भी nx पसंद है, और shared code को “library” में ले जाता हूँ। non-built library इस्तेमाल करता हूँ, और बड़े प्रोजेक्ट में यह काफ़ी अच्छा है
अभी TypeScript compiler API नहीं है, लेकिन इस पर काम हो रहा है, इसलिए उम्मीद है
- यह 7.1 में आने वाला है
memory usage कम होने और performance बहुत बढ़ने वाला graph देखकर लगता है कि server side पर TypeScript की जगह Go इस्तेमाल करना चाहिए, है न?
- पहले तो server side पर TypeScript चलाया नहीं जाता। कोई भी execution engine हो, आखिर में transformed code या JavaScript ही चलती है
  और आजकल इतने विकल्प होने के बावजूद लोग TS/JS/Python में नए प्रोजेक्ट क्यों शुरू करते हैं, यह मुझे सच में समझ नहीं आता
- शायद इसलिए कि frontend प्रोजेक्ट के साथ types या modules share किए जा सकते हैं। CPU-intensive न होने वाले application में शायद लगभग कोई फ़र्क नहीं पड़ता, या फिर लोग इससे परिचित हैं और इसे पसंद करते हैं। library ecosystem का बहुत बड़ा होना भी एक वजह है
- यह build time performance है, runtime performance नहीं
- Go और JS(Node वगैरह) के performance difference की अहमियत use case पर निर्भर करती है। TypeScript compiler के लिए यह निश्चित रूप से अहम है, लेकिन CRUD app के लिए शायद बिल्कुल भी नहीं
- अगर संभव हो, तो एक ही मुख्य language में काम करना ज़्यादा आसान होता है
TypeScript टीम को बधाई। इस पर लंबी पोस्ट या audio में कहने लायक बहुत कुछ है, लेकिन संक्षेप में कहूँ तो JavaScript/TypeScript ecosystem लकड़ी के काम जैसा है
आप सस्ते laminated particle board से Ikea-स्टाइल चीज़ें भी बना सकते हैं। कोड की दुनिया में वह मौलिकता-रहित vibe coding app जैसा होगा।
दूसरी तरफ, बेहतरीन handcrafted furniture या लकड़ी की ऊँची इमारतें भी बनाई जा सकती हैं। जैसे कम उम्र की लकड़ी, custom joints और lamination techniques से fire-resistant beams बनाना। JavaScript/TypeScript ecosystem में भी AI को एक शक्तिशाली machine tool की तरह इस्तेमाल करते हुए कारीगरी के साथ उच्च-स्तरीय नतीजे निकाले जा सकते हैं। अगर आपके पास कुछ बनाने और उसे चलाने की हिम्मत है, तो TypeScript/JavaScript ecosystem को अपनाया जा सकता है

Codebase	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

GN⁺ 2 시간 전

Lobste.rs की राय

वजह समझ में आती है, लेकिन self-hosting compiler से non-self-hosting compiler की ओर जाना दिलचस्प है
आम तौर पर दिशा लगभग हमेशा उलटी होती है, इसलिए यह एक दुर्लभ ट्रेंड है
- मुझे लगता है कि ऐसी दिशा हमें और ज़्यादा देखनी चाहिए। हर भाषा compiler लिखने के लिए उपयुक्त नहीं होती
  self-hosting भाषा पर मजबूत दबाव डालता है कि वह compiler बेहतर लिखने वाली भाषा के रूप में विकसित हो, लेकिन यह हमेशा सही दिशा हो, ज़रूरी नहीं
- भाषा designers और implementers यह समझते हैं कि उनकी अपनी भाषा हर use case के लिए परफेक्ट नहीं है—यह हैरानी की बात है
भले ही आप TypeScript में coding न करते हों, VSCode खुद TypeScript में लिखा है, इसलिए सोच रहा हूं कि क्या यह सुधार VSCode की speed पर भी असर डालेगा
या यह सिर्फ TypeScript language extension पर असर डालेगा
- compiler तेज़ होता है, यह जादुई तरीके से तेज़ code generate नहीं करता
- यह सिर्फ TypeScript language extension से संबंधित है
- TypeScript JavaScript में compile होता है। जब VSCode चलता है, तो node.js और Chromium JavaScript code execute करते हैं
  यहां जो तेज़ होता है वह केवल वह compiler है जो TypeScript code लेकर उसे JavaScript में बदलता है, और यह प्रक्रिया Microsoft द्वारा VSCode executable distribute करने से पहले build pipeline में होती है
  एक संभावित exception यह हो सकता है कि TypeScript LSP server भी तेज़ हो जाए, क्योंकि वह वास्तव में runtime पर TypeScript code parse करता है। हालांकि यह इस बात से अलग है कि VSCode TypeScript में लिखा गया है
- TypeScript compiler असल में बहुत ज़्यादा काम नहीं करता। tsc के बारे में principle है कि type removal जैसी न्यूनतम चीज़ों को छोड़कर उसे process हो रहे code को नहीं छेड़ना चाहिए, इसलिए काफ़ी चीज़ें WONTFIX के रूप में mark हो जाती हैं
  इसलिए TypeScript से बने tools की performance characteristics लगभग बदलने की उम्मीद नहीं है
व्यक्तिगत तौर पर मिला एक छोटा tip है। जिस project पर मैं अभी काम कर रहा हूं वह TS 5 इस्तेमाल करता है, लेकिन उम्मीद के मुताबिक मैं nvim में उसे इस्तेमाल नहीं करना चाहता था
इसलिए पहले mise से TS 7 install किया, और node_modules/.bin के अंदर mise से install किए गए TS की ओर point करने वाला tsgo symbolic link बनाया
क्योंकि nvim-lspconfig अभी भी technical preview के समय वाला पुराना tsgo filename इस्तेमाल करता है, nvim local TS की बजाय install किया हुआ TS 7 चलाने लगता है

TypeScript 7.0 की घोषणा

Go-आधारित native TypeScript

development feedback loop को छोटा करना

build performance और memory results

real codebase validation और team feedback

TypeScript 6.0 के साथ parallel execution

parallelization control options

`--checkers`

`--builders`

`--singleThreaded`

नया `--watch` mode

TypeScript 6.0 defaults और compatibility changes

हटाए गए या hard error बने behaviors

template literal types और JavaScript support changes

एडिटर फीचर्स और सीमाएं

embedded language workflow की मौजूदा सीमाएं

आगे की योजना

2 टिप्पणियां

Hacker News की टिप्पणियाँ

Lobste.rs की राय

TypeScript 7.0 की घोषणा

Go-आधारित native TypeScript

development feedback loop को छोटा करना

build performance और memory results

real codebase validation और team feedback

TypeScript 6.0 के साथ parallel execution

parallelization control options

--checkers

--builders

--singleThreaded

नया --watch mode

TypeScript 6.0 defaults और compatibility changes

हटाए गए या hard error बने behaviors

template literal types और JavaScript support changes

एडिटर फीचर्स और सीमाएं

embedded language workflow की मौजूदा सीमाएं

आगे की योजना

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

2 टिप्पणियां

Hacker News की टिप्पणियाँ

Lobste.rs की राय

`--checkers`

`--builders`

`--singleThreaded`

नया `--watch` mode