TypeScript Roadmap: January - June 2021

Roadmap Overview

This roadmap is meant to give our team and users clarity over our priorities over the next year. 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 roadmap, you will notice that our goals and areas of investment haven’t changed - so much so that our last roadmap sufficiently covered all of 2020. 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:

• More types as keys for index signatures
• Continued investment in template string types and tuple types
• Expanded non-strict checks (e.g. override, no property access on index signatures, unknown in try/catch)
• Running under multiple runtimes with conflicting global declarations

Back to top

JavaScript: TypeScript beyond TypeScript

• Making the JavaScript editing experience better
• Smoothing the transition to TypeScript
• Leveraging analyses outside of checkJs
• 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
• leveraging TypeScript to provide stronger hints in the untyped editing experience
• polish in the existing .d.ts file generation from .js files
• improving parity for JSDoc mode where appropriate (e.g. supporting a broader set of tags)
• investigating /// comments

Back to top

Committee Representation and Standards Compliance

• Supporting modern module patterns and formats
• Advancing committee work on decorators
• ES/CJS module interop
• Expression-oriented constructs

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, and we are also helping champion features which are highly-demanded from the community. 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

• UX around refactorings/quick fixes
• Improve experiences in partial semantic editing, such as during project load, or in-browser code exploration
• Invest in support for the Language Server Protocol
• Investigate opportunities to make getting started easier

Partial semantic mode has allowed editors to provide a better experience in single files while waiting for full projects to load; at the same time, we’ve seen that this mode can benefit in-browser scenarios as well. We’ll be smoothing out the experience there as opportunities and issues arise.

We’ll also be scoping out support for the language server protocol over time. Most editor support will likely continue to use TSServer in the near future, but we’ll be investigating what it takes to provide an LSP server for TypeScript as well.

Back to top

Speed, scalability, and stability

• Provide user-level tooling for profiling tsc builds
• Address top-hitting stability issues from telemetry & crawlers
• Investigate long-run performance wins
• Document best practices

We’ve learned lots from users over the past year in investigating slow builds. We’ve documented some best-practices for keeping builds fast, and we’ve built some tooling and options like --explainFiles and --generateTrace. We’ll continue improving our diagnostic tooling as we learn more.

Back to top

Education and UX

Handbook and Website

• Investigate, experiment, and improve user flow
• Transition docs to the new handbook
• Better onboarding for configuration and creating projects
• Ensure site continues to be accessible

The new website has been launched, and our handbook gathering feedback there. We’ll switching over to the new handbook by default this year.

Back to top

Error and type display UX

• “Smarter” diagnostics
• More related error spans
• Investigate interactive diagnostics and quick info

This area continues to receive investments, where we find heuristics to make the compiler “smarter” and provide more actionable errors.

Back to top

Community investment

downlevel-dts

downlevel-dts has been a useful tool for several partner teams. 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. We’d like to document this more as part of the “blessed” flow in writing libraries, and continue investment in the tool.

Back to top

DefinitelyTyped

• Weekly DefinitelyTyped rotations
• Surrounding infrastructure
  • DefinitelyTyped Tools
  • 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
• Invest in support for the Language Server Protocol
• 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

• Invest in profiling and tracing improvements
• Invest in automated test running UX
• Invest in various quality-of-life GitHub Actions

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.

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

We are not a company-wide build infrastructure team, but 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 our peers 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 often isolate 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

[awerlogus]

I have some thoughts to say.

Smoothing the transition to TypeScript

transitioning to TypeScript

I believe that the better idea is to migrate from TypeScript to checkJs and that’s why:

Code readability and aesthetics

TypeScript is a very “Horizontal” language, which means that it makes us write very (VERY) long lines of code because the types and the runtime code are declared on the same line here. The better practice is to write more code lines, but make this lines shorter. If I can write 2 lines of code with the length of 2/3 of original line, I would prefer this. And checkJs gives us this opportunity by separating the types and the runtime code. Feel the difference:

type Option<T> = T | undefined

export const map = <P, R>(func: (arg: P) => R) => (data: Option<P>): Option<R> => data !== undefined ? func(data) : undefined

/** @template T @typedef {T | undefined} Option */

/** @type {<P, R>(func: (data: P) => R) => (data: Option<P>) => Option<R>} */
export const map = func => data => data !== undefined ? func(data) : undefined

sure, we can chop that TypeScript function into a 3 lines like this:

type Option<T> = T | undefined

export const map = <P, R>(func: (arg: P) => R) => 
(data: Option<P>): Option<R> => 
data !== undefined ? func(data) : undefined

But it didn’t make the code more readable at all. We can also see the main problem of such code chopping in TypeScript: some code line may be surrounded by lines that are up to 10 times longer or shorter. It typically looks like

export function notSoLongFunctionName<
T extends VeryLongGenericConstraintTypeName<AlsoLongGenericConstraintParameterTypeName>,
P
> (
parameterName: LongParameterType<T, P>,
param2: number,
parameter3: VeryLongParameterTypeName<T, P, SomeLongTypeName>
): AlwaysTheMostLongThingInTheFunctionTypeDeclarationIsItsReturnType<T> extends number 
? BecauseOfExtendsChecksAndSomeOtherThings
: never {
  const stateMap = new Map<string, VeryLongMapElementType<T, P>>()

  // other runtime code
}

It’s ugly. I guess https://github.com/microsoft/TypeScript/issues/42388 is created to partially solve this problem by determining how function generic parameters should be chopped, but we still have also function parameters and return type. This problem also persists in the runtime code too. The nice example is a creation of some Map where we pass its key and value type parameters in the same line with the variable declaration as in the code above.

No need to compile

The need to compile is not a big problem as the previous one. But anyway it may help you to start a new node.js project quicker if you don’t need to setup any build tools. Just commit your code, pull it on production and it’s ready to run.

checkJs problems

Of course, checkJs isn’t without its problems either. The main one is that there’re some features that are supported by .ts files, but not by checkJs. We can’t pass generic parameters into a function, can’t use as const etc. We figured out how to live with it, so I just ask you to not add any more features in the future that increase difference between typed JS and TypeScript as a language.

d.ts generation for .js files

polish in the existing .d.ts file generation from .js files

I tried this feature. The first drawback is that imports of types from other files are not preserved. Instead it produces type declaration duplicates. It may be fixed with https://github.com/microsoft/TypeScript/issues/22160 if it will be implemented ever. The second thing is a lack of preserving empty lines between generated declarations.

Development priority

I think our new ability to work with string literals is very helpful, but we are still deadly limited in library development because of impossibility to determine that we expect not abstract number, string, object or array, but literals. Many libraries use models based on literals which are passed as parameters and then handled on both type and runtime levels. But nothing prevents you from passing just string or Record<string, any> there and breaking all type checks by it. So I believe that solving this problem is much more important than all together OOP typing problems that are currently being worked on. Issue: https://github.com/microsoft/TypeScript/issues/41114

[velociwabbit]

I realize i am going against the grain here but the average coder now has a minimum 1920 x 1080 screen and more often than not a 4k screen.

rather than make a case I will simply copy a gif that makes it for me.