Repository navigation
TypeScript 4.0 Iteration Plan #38510
Description
Activity
- pinned this issue
on May 12, 2020 Would you consider to include #29818 in 4.0 maybe behind experimental flag?
Reacted by WJH, csha and Anthony DresserThat gets complicated by the change in factory function definition in itself.
It could be interesting to introduce a separate factory virtual type definition, though; say,
JSX.Factory, orReact.JSX.Factory, which TypeScript could then use for inference. I'm not quite sure just translating JSX grammar to function calls is sufficient or efficient but, since it's a virtual type, it doesn't have to correspond to any concrete JavaScript entity. The risk, of course, is getting into the same situation as we have now, with a bunch of virtual types that ended up limiting the type safety, not only of children, but of several features introduced after React 15.Would you consider to also include #24738 in 4.0 as well?
Reacted by Benedict Aas, Li Feng Yu and ELFoglaltI'm a bit sad to see no mention of #33038 [👍 140 and an actual PR by your own Wesley Wigham (@weswigham)] or #202 [👍 390] while tickets like #15230 [👍 27] are considered "high-demand". I realise you can't really compare or prioritise on the basis of "likes" but it would be great if there was some roadmap update on these, especially as 4.0 seems like nice opportunity to introduce a feature like this. 🙏
Reacted by Sam A. Horvath-Hunt, Naji Astier, Aleksey Bobyr, Shinigami, Mathias Wulff, ⊣˚∆˚⊢, Nickolay Platonov, Ryan Smith, Moritz Mahringer, Sean Vieira and 2 more~3.5-year-old issue awaiting feedback with almost 200 comments #13778 with inaccurate typings provided for stuff like array destructuring. Pwetty pwease can we implement fix 🙏
Reacted by Jason Dreyzehner, Simon Hessner, Simon Hänisch, Kirill Groshkov, Ivan Franco, Joel Jeske, Ifiok Jr., Shinigami, Lucas Santos, Kirill Korolyov and 41 moreReacted by x_ror, Josef and Soul_MasterReacted by Kirill Groshkov, Tingan Ho and JosefReacted by Kirill Groshkov, Ivan Franco, x_ror, Lev Izraelit, Josef, WJH and Thibault MalbrancheReacted by Simon Hessner, Kirill Groshkov, Ivan Franco, Luke, x_ror, Vladislav Botvin, Lev Izraelit, Josef, WJH and Thibault MalbrancheReacted by Kirill Groshkov, x_ror, Vladislav Botvin, Lev Izraelit, Josef, WJH, Thibault Malbranche and yun1234Reacted by Kirill Groshkov, Vitor Farias, Josef and Thibault MalbrancheI appreciate people occasionally boosting issues that they believe need attention on the roadmaps and iteration plans, but I think I need to be clear here -that "investigate high demand bug fixes" section was determined by looking through issues that were clearly causing a lot of papercuts but which seemed reasonable in scope. We're definitely still mindful of the issues mentioned, but some of them are not as scoped nor do they have a clear ideal outcome.
Examples:
- Nominal brands would be nice, but would that compose with future language direction around nominality? I even have this concern with placeholder types as the person who proposed it.
undefinedon index signatures is an example of something that's interesting, but we don't want to add behavior that makes it harder for 90% of people who already operate under the current assumptions. Finding an approach that composes and allows users to incrementally adopt those checks isn't something that's obvious to us. Even if it's technically possible with a bunch of conditional types and special compiler checks, those solutions tend to be very clearly hacky and break down fast.
Reacted by Abraham Williams, Max, ExE Boss, Ivan Franco, Nick Ribal, Ghislain B., Bodo Graumann, Vladislav Botvin, Aleksey Levenstein, Josef and 7 moreReacted by WJHReacted by Sean Vieira, csha and Flavio VilanteNominal brands would be nice, but would that compose with future language direction around nominality?
Daniel Rosenwasser (@DanielRosenwasser) what is the future language direction in your vision?
Reacted by Shinigami and Sean VieiraI guess I'll give some context on where my mind is with nominality. There are a lot of different ideas people have in mind when they ask about nominal types, including
- "Traditional" declaration-based nominality (e.g. what you see in most OO languages)
- Opaque types (types whose contents are entirely unknown outside)
- Distinct aliases (single-member
structs in C/C++/C#,newtypein Haskell, inline classes in Kotlin) - Units of measure (a way to encode dimensional analysis into the language)
There are shades between some of these (e.g. placeholder type declarations - kind of variant of opaque types that fall back to an implementation type), and then there are different directions that blend each of these together.
Ryan Cavanaugh (@RyanCavanaugh) had a great analogy about this where 3 kids are asking their parents for a pet. One wants a dog, one wants a cat, one wants a fish. They ask their parents "when are we getting a pet!?" Clearly they all agree they want a pet, but each wants a different pet!
Do I like branded types? I do! Branded types achieves something like distinct aliases, and fits the bill for what most users are looking for. But I don't think that's the right way to think about it. There's more design space to be fleshed out with plenty of known tradeoffs, and nothing giving me a sense that we need to rush a solution ASAP.
Reacted by Abraham Williams, Amin Pakseresht, Jack Works, Toni Villena, ZHAO Jin-Xiang, Bnaya Peretz, Madara Uchiha, Nick Ribal, Benjamin Gruenbaum, ExE Boss and 14 moreReacted by Sean VieiraI’d like if we could get microsoft/TypeScript-DOM-lib-generator#858 into TypeScript 4.0.
Reacted by ELFoglaltDaniel Rosenwasser (@DanielRosenwasser) first of all thank you for the writeup 🙇
Can you elaborate a bit on what use cases nominal types actually address for TypeScript?
First: feel free to send me to a giant wall of text or a repo and I'll read it :]
I don't mean opaque types like placeholder types - I mean what you call "Traditional" nominal types.
I always felt nominal types were antithetical to JavaScript and that's why previous attempts didn't really work so well. There are ways to make it work pretty nicely (protocols in swift and typeclasses in haskell come to mind as "Nominal but extendable from the outside") and I'm sure you're familiar with most of the "well established" ways (I assume "units of measure" is an F# wink).
I have found a lot of people asking for nominal (as in "traditional") types but not a lot of writeups about why.
Reacted by Shinigami, ExE Boss, Daniel Rosenwasser and SlurpTheoOver time, we've seen fewer and fewer people request "traditional" nominal types, maybe because collectively the community has built up a mental mode for structural types. There are some places where types truly do act nominally (when
instanceofis involved or when there are privates). Some of that is captured with better control flow analysis and compatibility checks, but it's not perfect.Some of the "traditional" use-cases are the same as those of a zero-overhead nominal wrapper type (e.g.
newtype), and a lot of the time the intent there is to ensure special handling for things like file paths, untrusted strings, etc.Reacted by Benjamin Gruenbaum, Bnaya Peretz, Sam A. Horvath-Hunt, Aleksey Levenstein, Zhihao Zhang, Sean Vieira, Joe Percy, Sean Kelley, Okku and SlurpTheoI kind of feel that Typescript is already expressive enough. What I would personally would like to see is better tooling integration.
- support for ESM New --emitExtension and --noImplicitExtensionName compiler options #35148 Provide a way to add the '.js' file extension to the end of module specifiers #16577
- compiler plugins Allow "Compiler Plugins" #16607 Pre-Compiler Plugin Proposal #38736
- yarn pnp Add new moduleResolution option:
yarn-pnp#28289 Native support for PnP #35206
Because of above it is common to see clunky and hacky solutions. Most react projects have babel included for react-hot-loader (compiler plugins), some CSS systems also require babel for compile time transforms. Using pnp, esm or even CSS modules require more tooling and workarounds for tsc limitations.
It is also frustrating that for some of these issues community came with concrete solutions in form of PRs or proposals but these were rejected or stalled for years. As a practitioner, it is getting harder to use TS in the context of wider ecosystem.
Anyway I am just random person from internet.
Reacted by Arpad Borsos, Steven, Kirill Groshkov, Jacob Gillespie, James Robb, Piotr Oleś, Melvin Valster, knightlore, Goszczu, Alec Mev and 67 moreReacted by notaphplover, Michael Luo, Julius Bagdonas, Dotan Simha, Jon Nyman, William Luke, rvion and MarcoReacted by Kirill Groshkov, David Else, Rúni Brockie, Josef, Denis Karabaza, Michael Luo and Dotan SimhaReacted by Thomas Mur and Dotan SimhaDaniel Rosenwasser (@DanielRosenwasser) maybe #29374 could get reviewed in time for 4.0? I think it covers many (most?) of the
this-before-supercases folks tend to ask about.41 remaining items
it's Aug 20 :)
Reacted by Daniel Rosenwasser, Marko Jakic, Erik Krogh Kristensen, tsingwong, Matěj Pokorný, Toni Villena, DmitryScaletta, btoo, Marta and SlurpTheoHeh, it's still August 19th here, and even 20 minutes from now I think you'll have to wait a bit more. We have nightly releases on npm if you can't take another minute! 😄
Reacted by jdmichaud, Toni Villena and Aravind AReacted by Adrien Lemaire, ZHAO Jin-Xiang, jdmichaud, AsukaSong, Benjamin Gruenbaum, Erik Krogh Kristensen, Toni Villena, Sam A. Horvath-Hunt, Steven, DmitryScaletta and 6 moreWaiting for the release, already out in npm :)
Reacted by Toni VillenaTypeScript Bot (@typescript-bot) bump release-4.0
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-4.0to4.0.3for you. Here's the link to my best guess at the log.TypeScript Bot (@typescript-bot) bump release-4.1
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-4.1to4.1.1-rcfor you. Here's the link to my best guess at the log.Oh no
Reacted by Ryan Cavanaugh, Sam A. Horvath-Hunt, Toni Villena and resynth1943TypeScript Bot (@typescript-bot) bump release-4.0
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-4.0to4.0.4for you. Here's the link to my best guess at the log.TypeScript Bot (@typescript-bot) bump release-4.0
Reacted by Jacob Haubach Smedegård and StevenHeya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-4.0to4.0.5for you. Here's the link to my best guess at the log.TypeScript Bot (@typescript-bot) bump release-4.0
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-4.0to4.0.8for you. Here's the link to my best guess at the log.
This document outlines our focused tasks for TypeScript 4.0, as well as some of the discussion that explains how/why we prioritized certain work items. Nothing is set in stone, but we will strive to complete them in a reasonable timeframe.
Language Features
awaitedTypeunknownoncatchClause BindingsEditor Productivity
/** @deprecated */tags/** @see */tagsPerformance
Infrastructure
Investigate High-Demand Bug Fixes
--watch--declarationEmit Errorchangeevents on<input type="file">have nofilesfieldisolatedModules