TypeScript 3.4 Iteration Plan

[DanielRosenwasser]

This document outlines our focused tasks for TypeScript 3.4, 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.

Dates

Officially, here's the plan:

1. March 8th (12pm Pacific): Create a release-3.4 branch, and update the version to 3.4.0-rc. master is locked from receiving new feature-work that is not 3.4-bound.
   1. Start a build of TypeScript for Visual Studio for our remote testing team.
2. March 13th (12pm Pacific): Last day to adjust the release-3.4 branch with any feedback we receive.
   • Kick off a final Visual Studio build if necessary.
   • Produce an insiders release for VS Code.
3. Morning of March 14th: The release candidate goes out.
4. March 22nd (12pm Pacific): Merge master into release-3.4 one last time, finalize the version as 3.4.1. master is unlocked. Critical changes for 3.4 must be ported in.
   1. Start a build of TypeScript for Visual Studio for our remote testing team.
5. March 27th (12pm Pacific): Last day to adjust the release-3.4 branch with any feedback we receive.
   • Kick off a final Visual Studio build if necessary.
   • Produce an insiders release for VS Code.
6. March 28th: Announcing TypeScript 3.4 🚀

Conclusions

How to read this:

Symbol	Meaning
✅	Work item is done
🏃🏻‍️	Work item is in progress
📖👀	Work item is in review
🤔	Work item is in speculative planning phase

Expected Work Items

• Language
  • const contexts ✅
  • readonly tuple/array type modifiers ✅
  • Various inference improvements
    • Improve contextual typing by generic rest parameters #30114
    • Higher order function type inference #30215
    • Infer contextual types from generic return types #29478
  • globalThis ✅
• Compiler
  • Incremental build digests for cold builds ✅
  • APIs for composite projects (--build mode) 🏃
  • Investigate plugin API 🏃
• Language service
  • Convert to named parameters ✅
  • Smart Select API 🤔
  • Convert function expression to arrow function, vice versa 📖👀
• Infrastructure
  • Benchmarking infrastructure ✅
  • Moving builds to Gulp ✅
  • DefinitelyTyped infrastructure ✅
  • Automated testing language service infrastructure for real world code 🤔
  • ESLint parity with TSLint for semantic checking 🏃

Deferred Work Items

• Negated types
• Partial type argument inference
• Decouple JSX expression types from JSX namespace
• --declaration with --allowJs

---

Planning Meeting Notes

Motivations

• Goals and current 6-month roadmap
• GitHub user feedback (👍s)
• Feedback from customer interviews and social media.
• Visual Studio and Visual Studio Code feedback and new functionality demands
• Actionable PRs (need to make a call)
• Bug backlog

Discussion

General (compiler/infrastructure/reliability)

• Partial type argument inference
  • Current designs have issues, and not enough consensus on team for proposed solutions.
  • Declared as on-hold.
  • ⛔
• const contexts
  • Merged ✅
• Better inference through return types
  • Merged ✅
• Propagation of uninferred generics
  • Merged ✅
• readonly type modifier for arrays/tuples
  • Merged, but...
  • Appears to be a large breaking change
    • breaks .d.ts consumption for older versions
    • issues with current consumers of displayed types (e.g. dts-lint) - how do you "expect" different displays of the same semantic type.
  • Needs investigation on workarounds.
• Negated types
  • PR out (WIP)
  • Open questions:
    • Can this model control-flow narrowing?
    • If so, does this lead to reasonable user experiences?
  • ⛔
• globalThis
  • ✅
• --declaration with --allowJS
  • Want to, but probably not 3.4-bound given high bug count.
  • ⛔
• Private fields
  • Still want to wait on stage 4.
• Types publisher infrastructure for DefinitelyTyped
  • ✅
• Performance infrastructure
  • Faster incremental cold builds by creating a "digest" file
  • "Pick-up-where-you-left-off" builds
  • --watch mode without a resident process.
  • ✅
• Getting rid of Jakefile.js 😢 and moving to Gulp
  • Consolidate on more modern tooling
  • Gulp 4 has an easier API
  • Potentially faster builds using watch mode
  • ✅
• JSX Factory decoupling
  • Pros: High 👍 count, language expressivity, strongly-types JSX Element expressions
  • Cons: Can break the world for re-assignments of JSX elements, can create big trees of types, and leaks details about APIs.
    • This can break API consumers 🌎🔥
  • Until we have a perf mitigation here, it's stuck. ⛔
• Composite project/--build APIs
  • Provides value to API consumers and makes --build more integrated with Webpack, Rollup, gulp, and any other build tool integration.
  • Potentially an experimental API for 3.4, but work will definitely accrue to something in 3.5 (at latest) with a stable API.
  • ✅
• Automated testing infrastructure
  • Earlier way to validate against real world codebases on GitHub
  • Part of this is that our own dog-fooding (🐶🍰) doesn't reflect the sort of code our users always do.
  • Investigating leveraging existing infrastructureto crawl external codebases and run language service operations on them.
  • 🤔
• Compiler plugin API
  • Minification is one of the most-demanded issues of all time.
  • We can't provide it, but we want to enable more tooling to leverage TypeScript APIs
  • Experimenting with a prototype for a new printer that can take care of basics, APIs to inject transforms into the tree from an invocation of tsc.
  • Entirely investigative, and depends on partner teams being able to utilize it - no clue if this will land in a stable release.
  • 🏃
• High bug count

Productivity

• Refactor to named parameters
  • High positive feedback on issue tracker
  • ✅
• Smart select API
  • Accrue value to VS Code and other consuming editors.
  • ✅
• Convert to arrow function/vice versa
  • Outstanding PR
  • ✅
• Class components to function components?
  • Seems pretty React-specific.
  • ⛔ can't be prioritized for 3.4

[j-oliveras]

You have globalThis under Expected Work Items and Deferred Work Items.

[DanielRosenwasser]

@j-oliveras it's still March, give me a break.

[jack-williams]

Negated types
Can this model control-flow narrowing?

I think this paper is very related: https://pnwamk.github.io/docs/sstot.pdf.

[yortus]

Can I ask about the status of #26797 as a work item? It's tagged for the 3.4 release but not mentioned here. It's been open six months now and has gathered many positive reactions (currently 4th most 👍'd and ❤️'d open PR and I think the other three are all covered here).

It was also previously tagged for the 3.3 release, and the the 3.2 release before that. It seems like this one will forever be in the 'next' release 😿

[babakness]

I hope the Higher order function type inference merge makes it!

#30215

[weswigham]

I think this paper is very related

I actually already have a branch that uses them for control flow; however I need to work on somehow making intersection construction less costly - as a truthyness check on a big union can become hugely expensive once truthiness is tested for via negations. :(

[weswigham]

Can I ask about the status of #26797 as a work item?

Last time I brought it to the table (or rather, in office discussion), we've discussed we need to take it in one of two ways to land it with confidence:

1. Forbid instantiable types in key positions. This is mostly because we lack confidence in the higher order behavior of the new index signatures, and how they interact with things like conditionals and generics.

2. Merge non-homomorphic mapped types and index signatures into a single concept. Conceptually, once indexes are open ended in terms of type, the only difference between an index signature and a mapped type should be the presence (or lack thereof) of a template. (And the fact that multiple mappings should be definable within the same type) By merging them and showing that things aren't too broken, we can be relatively sure that the relationships are good (since mapped types work pretty OK).

The first can be done pretty quickly (it's just an added grammar error), but is definitely lacking, IMO. The second is going to take some more effort. Since I'm a fan of full and complete fixes, I started work on the second (which is quite troublesome - there's actually a bunch of places where higher order mapped types don't behave quite right and they really stick out when you try to apply them to nongeneric types for index-like constructs; so finding the right middle ground between breakiness and correctness is desirable) but with the impending release, swapped to fixing a bunch of bugs, so we'd have a slightly less buggy release :3

For anyone watching it: sorry for letting it slip guys, but I am still working on it and it hasn't been abandoned. In fact, it's considered a prerequisite PR for negated types to land (since a primary use as involves negated index signature types to limit the scope of an index to keys not explicitly defined), so it's definitely still something I'm on. You'll probably see my work on it ramp back up after we ship 3.4 proper in two or so weeks.