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:

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