Closed
Description
This document outlines our focused tasks for TypeScript 3.5, 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
Here's the release plan.
- May 10th: Create a
release-3.5
branch, and update the version to3.5.0-rc
.master
is locked from receiving new feature-work that is not 3.5-bound.- Start a build of TypeScript for Visual Studio for our remote testing team.
- May 15th: Last day to adjust the
release-3.5
branch with any feedback we receive.- Kick off a final Visual Studio build if necessary.
- (2pm Pacific) Produce an insiders release for VS Code.
- Morning of May 16th: The release candidate goes out.
- May 24th: Merge
master
intorelease-3.5
one last time, finalize the version as3.5.1
.master
is unlocked. Critical changes for 3.5 must be ported in.- Start a build of TypeScript for Visual Studio for our remote testing team.
- May 29th: Last day to adjust the
release-3.5
branch with any feedback we receive.- Kick off a final Visual Studio build if necessary.
- (2pm Pacific) Produce an insiders release for VS Code which is identical to the final release.
- May 30th: Announcing TypeScript 3.5 🚀
Work Items
Expected Work Items
- Language
- Compiler
- Anticipated
--incremental
fixes and improvements -
--declaration
and--allowJs
-
--declaration
and--isolatedModules
- APIs for
--incremental
and composite projects (--build
mode) 🏃 - Investigate TypeScript plugin APIs 🏃
- Anticipated
- Language Service
- Infrastructure
- Automated testing infrastructure for language service on real world code 🏃🏻
- Migrate to ESLint 🏃🏻
(🏃🏻 means work has already started)
Deferred Work Items
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
General (compiler/infrastructure/reliability)
-
Negated types
- Rationale: Core type system
- Uses: control flow analysis on generic/"higher order" types
- Problems: But you end up with lots of vacuous intersections that are "garbage" types.
- Will likely lead to a tail of bugs, at least initially
- Action item: need to prototype, see what sort of breakage we see with implementations of integration with control-flow analysis, and see what the perf impact is.
- ✅ Work on this.
-
Arbitrary index signatures
- Rationale: Core type system
- Not a must for negated types
- But like to get them done first.
- Also need a unifying concept between them and mapped object types.
- Resolution: Defer
-
Compiler API prototyping
- Rationale: minification, 3rd party tools integration
- In progress
- ✅
-
Expecting
--incremental
build issues- Rationale: Stability, scaling, performance
- ✅
-
Crawler work for testing TSServer
- Rationale: Stability
- Context:
- IntelliCode team crawls public code to train on, but leverages TSServer.
- Turns out that it was a great way to test TSServer and catch bugs!
- We want to leverage it to get a good litmus that it's stable.
- Give partner teams assurance that they can adopt nightly TypeScripts.
- ✅
-
TSLint -> ESLint migration
- Internal engineering
- ✅
-
New engineer starting!
- Ramping-up bugs
- Website
- Education and UX
- ✅
-
globalThis
-related work- Bug and standards involvement
- Issues with block-scoped declarations interfacing with the global object.
- ✅
-
--declaration
with--allowJs
- TypeScript beyond TypeScript
- ✅ 🎉
-
--declaration
with--isolatedModules
- User demand
- Aside: Ensure this all works with
composite
. - Resolution: investigate
Productivity
- Smart Select API
- TSServer: Smart select API #29071
- VS Code ask, but generally applicable editor integration
- ✅
- Sorted/prioritized completions
- favor local types and values in autocomplete popup over ambients declaration #15024
- Editor quality improvements
- This and smart select have been around for long enough that they get priority.
- ✅
- Extract type refactoring
- Suggestion: Refactor extract to type alias/typedef #23869
- Shouldn't it just always work?
<T>(x: T): { value: T }
- It has all the same problems as extract method!
- Well you don't have to worry about control flow.
- Could just do this for non-generic types for the minimal-viable product (MVP).
- Resolution: try to get done for 3.5. ✅
- Call hierarchy breadcrumbs
- Feature request: Call Hierarchy vscode#16110
- VS Code ask, but generally applicable editor integration
- Resolution: Probably will defer to next version.