Roadmap Overview

This roadmap is meant to give our team and users clarity over our priorities until June. It's meant more as a set of guidelines than as a strict set of tasks we are bound to finish.

At a high-level, we're going to be focusing on the following 5 goals:

• Types on every desk, in every home, for every JS developer
• Productivity through strong tooling
• Approachability and UX
• Community engagement
• Infrastructure and engineering systems

The how is broken down into the following sections:

• Language design and innovation
• Developer productivity tools and integration
• Education and UX
• Community investment
• Internal engineering

If you've seen our last 6-month roadmap, you will notice that our goals and areas of investment haven't changed. The biggest changes you might notice are specific work items and amount we'll be focusing on each area of investment.

Language design and innovation

TypeScript and the core type system

• Enabling popular JS patterns in a type-safe way
• Increasing expressivity
• Proving relationships between types
• Stricter settings
• Implementing ECMAScript features

The goal of TypeScript's type system is to statically model patterns in JavaScript in a reasonable way while catching bugs and enforcing correctness. As more features are added to ECMAScript, and as we notice emerging patterns in the ecosystem, we have more work to do, and because the JavaScript world moves fast, so must we.

While nothing has changed here, new areas of focus might target a few core issues like:

• running under multiple runtimes with conflicting global declarations
• the nature of Promise unwrapping on generic types
• exploring different approaches to nominal types
• experimenting with local type declarations within types

Back to top

JavaScript: TypeScript beyond TypeScript

• Making the JavaScript editing experience better
• Smoothing the transition to TypeScript
• Automating the addition of JSDoc types
• Understanding more dynamic patterns

TypeScript isn't just for TypeScript anymore. Our userbase now includes the JavaScript ecosystem as a whole, whether they are

• using .js/.jsx files in editors powered by TypeScript,
• compiling purely with allowJs,
• type-checking with checkJs (also enabled by the // @ts-check comment), or
• transitioning to TypeScript

Whoever these users are, we believe TypeScript can serve them in some way.

We largely expect investment in the following areas:

• editor tooling
• polish in the existing .d.ts file generation from .js files
• improving parity for JSDoc mode where appropriate (e.g. fixing up generics and supporting a broader set of tags)

Back to top

Committee Representation

• Class fields (public and private)
• Decorators
• ES/CJS module interop
• Pipeline
• Pattern matching
• Enabling more expression-oriented styles
• Protocols

We are involved in several different committees, including TC39 and the Node modules group. We try to provide representation as

• implementers of TypeScript, the type-checker
• implementers of JavaScript language services & tooling
• a voice for the users of both of the above

We're prioritizing forward compatibility with proposals/features that we've adopted early on. For now, we will mostly act in an advisory manner for outstanding proposals. To maintain focus, we will likely only be engaged with a few proposals at a time.

We hold a policy of not implementing features unless they reach stage 3 and we have high confidence in them.

Developer productivity tools and integration

Editor productivity

• Editor responsiveness and faster project load times
• Reducing paper cuts
• UX around refactorings/quick fixes
• Moving more contextual information to TS Server
• Investigate Language Server Protocol
• API protocol discussions with partner editor teams
• Ensure fast syntax colorization on TS Server
• Swappable project contexts (editor switching between different tsconfig.json files)
• Support experiments around project wide error reporting efforts

More details here.

While editor responsiveness would typically land under speed, scalability, and stability, it is worth noting here because it has consistently come up as a problem. We've fixed many responsiveness bugs, and have continued to follow up with different users to understand where TypeScript isn't performing optimally. We have some ideas around I/O speed improvements and potentially migrating to a process-per-project model for TS Server to ensure cross-project navigation never blocks on projects that are already open. We also acknowledge that we will need some infrastructure for server scenarios.

We've been aware of some of the sub-optimal UI/UX around how our refactorings and quick fixes are requested and surfaced. One fairly clear issue is that our support for refactorings is often too finicky - we require very precise ranges around expressions and statements, and that can limit discoverability. A more open-ended issue is how to surface refactorings beyond what we have today. Can we make refactorings triggerable without a range where TypeScript can "infer" appropriate ranges? Is there a better UI to surface beyond a list of fixes/refactorings intermingled? These are areas worth exploring in the next 6 months.

Regarding swappable project contexts: Today, TS Server (and hence, your editor) always associates a file with the first tsconfig.json it can find walking up the chain of directories. That might be a problem in a codebase with multiple configuration files (e.g. a tsconfig.json and a tsconfig.test.json). Swappable project contexts will provide users with an easier way to edit with different build contexts - for example, differences in development and production builds, test projects, and perhaps multiple target environments (e.g. tsconfig.web.json, tsconfig.ios.json, tsconfig.android.json, etc.).

Regarding contextual information in TS Server: Editors like VS Code have their own logic to figure out things like the right sets of characters to trigger auto-complete, or how to colorize the code in a file, on their own. On the other hand, TypeScript's language service often lacks information for why an operation was performed. These are instances where each tool has to assume more than it reasonably can, and also leads to other problems. For example, code colorization happening as part of the editor might be a problem for "thin clients" (e.g. remote sessions) where TextMate grammar classifiers can impact responsiveness. As a result, we'll be investing in helping editors delegate to the language service.

Regarding Language Server Protocol (LSP): as Visual Studio builds out deeper integration for languages leveraging the LSP, the JavaScript/TypeScript Tools for Visual Studio team has working on implementing LSP support for TypeScript. The work and investigation is still in early stages.

Back to top

Linting

• Editor integration for ESLint
• Speed and scalability in editor scenarios

We've seen that there are areas for improvement in ESLint integration, both for JavaScript and TypeScript.
The main few things that we're being mindful of is

• Initial setup experience with TypeScript and ESLint
• Performance issues in TypeScript and ESLint
• Editing scenarios for ESLint, regardless of TypeScript integration

It's not clear exactly what has to improve, but we'll be keeping a watchful eye here.

Back to top

Speed, scalability, and stability

• Project references parellelization
• Investigate permitting circularities in project references
• Dive into common libraries that exhibit poor check times (e.g. styled-components and material-ui)
• Investigate continuous logging infrastructure
• Learn to profile better
• Implement ways to get quick feedback from TS Server restarts

More details here.

Since we last started investigating, we discovered certain performance issues including slower performance on Windows in things like file-traversal, long check times when using certain libraries, and editor operations that are too aggressive in opening other projects or discarding contexts from open files. Early experiments for improving some of these appear promising, so we expect to see some work go into this area;
however, much of what we discovered was also that profiling memory allocations in JavaScript applications is really hard. Infrastructure seems lacking in this area (e.g. figuring out what is being allocated too much), and much of our work may reside in learning about more tools, or building some out.

One area we'll also be investing in will be parallelized --build mode for project references. There's long been potential to build several different projects in parallel, and while consumers of TypeScript's project references APIs can certainly implement this behavior, this seems like a clear win for everyone using tsc --build.

We've

When it comes to stability, we've had a hunch that we could be doing better. It definitely feels like users often end up restarting TS Server, or the entire editor itself. While it's good that the option to do so exists because no product is perfect, this shouldn't become the norm for users. Today we get various crash reports from editors when the language service crashes or violates an assertion - but we're not hearing why users are restarting the editor/language server when something goes wrong. This is understandable. Taking the time to report an issue is a lot of work. We'd like to drive down the number of crashes and also get some quick feedback when users choose to restart TS Server in the Visual Studio family of editors. Finally, we also are interested in a way to enable logging by default (since we already do this with ETW), but because there doesn't seem to be an easy cross-platform built-in way to do this, we might build one for TS Server.

Back to top

Education and UX

Handbook and Website

• Better onboarding for different types of developers
• Refreshed look & feel
• Drive accessibility
• Make the playground better for playing in

The handbook is close to done, and can be viewed here. The new website is coming together as well. We'll defer work around the new website to the Website Roadmap.

Back to top

Error and type display UX

• "Smarter" diagnostics
• More related error spans
• Interactive diagnostics and quick info

More details here.

We've made further improvements in UX and error messages, with help from the community, and are carefully monitoring feedback from users around this. We don't have specific action items, but we will try to brainstorm on tough messages. One thing that we have recognized is that error message improvements have been a great way to involve others in the TypeScript community, who can often provide input beyond what our team thinks of.

We have been experimenting with editor UX changes that make it easy to explore types in quick info (editor tooltips) and error messages. We're holding these changes until we finish user studies on whether they actually help users fix issues more quickly.

Back to top

Community investment

downlevel-dts

downlevel-dts is a tool that we've had requested many times over the past few years. It lets library authors rewrite .d.ts files so that they can be consumed by older versions of TypeScript. For example, for Typescript 3.6, .d.ts files with get accessors in classes need to be rewritten to property declarations. This tool will need ongoing investment for each release containing new .d.ts syntax.

Back to top

DefinitelyTyped

• Weekly DefinitelyTyped rotations
• Surrounding infrastructure
  • types-publisher
  • dt-mergebot
  • dtslint

Back to top

External contributors

• Weekly meetings to drive down outstanding pull requests
• Dedicated time from engineering team to assigned pull requests following release candidates

Back to top

Partner teams

We'd love to hear from your team if you use TypeScript in interesting or broadly applicable ways. This gives us insight on various things we could improve. Please give us your feedback!

Back to top

API Consumers

• Rolling requests for API endpoints
• Provide help for consumers trying to provide richer experiences like Vetur
• Investigate improving rich editing experiences
  • in enhancing plugins like IntelliCode
  • in templates

Back to top

Outreach

• Public talks
• Meetup attendance
• In-depth blog post content
• Help with TSConf coordination

We want to encourage members of our team to be involved with the community, and write and talk about things that they find interesting. This keeps us close to our users and makes the project itself more approachable.

Internal engineering

Team infrastructure

• Enabling parallel builds on our own codebase when available
• Circular buffer logging for TS Server
• Investigate building out memory profiling tools

The idea here is really anything that improves

• stability
• productivity
• ease of contribution

for development on the TypeScript project and any of our satellite projects.

Parallel builds will ideally speed up our build times.

Implementing our own circular buffer logging for TS Server may be the only way we can achieve cross-platform logging turned on by default with little cost.

We may consider building out memory profiling tools given that we need it, but few options exist for free.

Back to top

Organizational guidance

• Internal guidance on TypeScript-first API designs
• Providing internal partner teams with best practices for projects
• Addressing major Microsoft-internal build regressions

Because we have the expertise, and because we are involved with the JavaScript community, we're able to provide a level of guidance across Microsoft to give users better experiences all around. Additionally, when we hear about major build regressions on large codebases, our internal teams can provide us with their source code, allowing us to create minimal repros (which is not always the case with external closed-source codebases). This work usually benefits external users in some way, whether it's because a bug fix generalizes, because we've produced better APIs, or because we've been able to extract new guidance.

Back to top