I’ve got many TypeScript Christmas wishlist items, too, but I have to admit I disagree with a few of these! A new syntax for tuples is overkill. TS is already

I’ve got many TypeScript Christmas wishlist items, too, but I have to admit I disagree with a few of these! A new syntax for tuples is overkill. TS is already getting quite syntax heavy and I feel that the current methods for defining tuples are more than adequate—either with “as const” as described in this post or like “const foo: [number, boolean] = [5, true]” as the TS docs recommend for tuples. Runtime type evaluation—please no! This is the perfect domain for libraries to exist in. When you import a library, it’s explicit what’s going to happen at runtime. Libraries are easy to debug, forkable, and swappable. Baking this behavior into the compiler not only foregoes those benefits, but also makes the output less easy to predict and will of course add overhead to the compile. My own wishlist top 3: 1. Better following of type narrowing through branches and functions. After I filter out all nulls in an array or prove that some optional variable is definitely not undefined, there are still times when ts can’t tell that that’s the case. I can force it to with workarounds, but wish I didn’t have to. 2. Compiler perf improvements. Hard to disagree with you there! Esbuild locally and tsc in ci is okay-ish, but not an ideal state for the ecosystem to stay in for the long term. 3. Consolidation of tooling. For node do you go with tsc and run the output? Or ts-node? Esbuild locally and tsc in prod? Deno? Browser-side, similar questions but throw in Vite and all the other options, too, and even for someone working in this environment regularly, setting up a new project with all the proper tooling is far too much effort.