TypeScript Roadmap: July - December 2019

[DanielRosenwasser]

Roadmap Overview

This roadmap is meant to give our team and users clarity over our priorities over the next 6 months. 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 change you might notice are specific work items and amount we'll be focusing on each area of investment. As an example, we're still committed to supporting editor scenarios, but right now we're more interested in ensuring that editor features are fast.

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

This is a continuous and iterative process. 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, we have noticed any change we make may break existing code or hurt performance. We do not believe this should deter us from investment in these areas, but we will have to test more than before. More on this later in the document.

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.

The majority of our investment here will likely be for editor scenarios, migration to TypeScript, and targeting .d.ts file generation from .js files.

Back to top

Committee representation

• Optional chaining/coalescing
• Class fields (public and private)
• Decorators
• ES/CJS module interop
• Pipeline
• 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, and we are also helping champion features which are highly-demanded from the community. As an example, our team is now involved in championing optional chaining and nullish coalescing. 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
• "Bread and butter" fixes & refactorings
• Migration tooling
• "Proactive" quick fixes (i.e. suggestions)
• Declaration file fixes and refactorings
  
  
  
  • Generate missing .d.ts files
  
  
  • Locally fork @types package
  
  

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, but we still have more feedback to investigate.

"Bread and butter" quick fixes and refactorings refer to a class of code modifications and fixes that are applicable to most users, and generally improve everyone's quality of life. These fixes are also useful for teaching users about language features and patterns. Expect more of these, and feel free to suggest some in separate issues!

We've heard that migration is still a common pain-point, and we would like to invest in ways to ease migration to TypeScript and typed JavaScript. We have ideas here like automatic refactorings for when a file is renamed from `.js` to `.ts`.

Managing declaration files continues to be a problem, and we have more ideas for good workflows since we last considered this. We'll have to rethink our approaches here.

When possible, we may provide more in-editor suggestions with quick fixes, though these are nice-to-haves compared to the other features mentioned here.

Back to top

Linting

• Speed and scalability
• Editor integration for ESLint

ESLint is now a capable linter for TypeScript projects. There is room for improvement in editor scenarios, but we'll focus on core editor functionality and performance for JavaScript/TypeScript. We will monitor TypeScript integration in ESLint and assist the project when needed.

Back to top

Speed, scalability, and stability

• Project references/incremental polish and improvements
• Addressing performance issues
  
  
  
  • Finish ETW (Event Tracing for Windows) profiling support
  
  
  • Benchmark monitoring
  
  
  • Tracking down and fixing regressions
  
  
• Automated testing infrastructure for TSServer

More details here

Since the last roadmap, our benchmarking infrastructure is significantly better and uses more up-to-date versions of the 3rd party projects that we test against. We even have editor-style tests built into DefinitelyTyped to check whether any given test will significantly increase memory usage and keystroke delays. We're still continuing on automated testing infrastructure for TSServer to crawl external codebases to effectively fuzz-test them. ETW support is almost done, but is being wrapped up. We've also managed to address various regressions that have popped up.

In recent versions, we released the `--incremental` flag to enable faster compiles, with or without using project references. Still, when it comes to compiling and editing, our users have reported some scaling issues in performance. We're going to be reaching out to users to find the root cause of their issues, and finding patterns so that we can directly address the issues.

Back to top

Education and UX

New handbook

• Writing tailored intros for developers with different backgrounds
• Writing new core handbook
• Reference pages
• Infrastructure to replace look & feel, and subsume current publishing process
• Documentation around checkJs

More details here.

The handbook is close to done, and can be viewed here. We hope to be done with the core handbook in the coming months and to publish it to the new website around the end of the year.

Back to top

Error and type display UX

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

More details here

We've made further improvements in UX and error messages, with help from the community, as well as [feedback from Microsoft's API teams](https://github.com/microsoft/TypeScript/issues/30646) from user studies around Promise-based APIs using TypeScript. We'll continue to look for feedback from these sources.

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

Playground and website

• Redesign
• Handbook integration
• New community pages
• Update examples on the website
• Playground
  
  
  
  • Nightly versions of TypeScript in the playground
  
  

We've already replaced the playground, and have been investigating as to whether we can make nightly versions available. We will also be working on a redesign, new pages around community meetups/conferences, and integrating the new handbook into the site.

Community investment

DefinitelyTyped

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

Back to top

External contributors

• Easier contributions to the docs
• Open contributions to the playground and website
• Automated PR process on TypeScript

Back to top

Partner teams

We continue to elicit feedback from various partner teams, including library authors and organizations/individuals using TypeScript in interesting or broadly applicable ways. This gives us insight on various things we could improve. If you or your organization have any interesting feedback, we'd probably love to hear from you!

Back to top

API Consumers

• Rolling requests for API endpoints
• 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

• Faster builds
• Linting on ESLint (and faster linting)

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.

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

[Kingwl]

Looking forward to the pipeline op very much. :XD

[AnyhowStep]

Help with TSConf coordination

The TSConf website doesn't really say much about what it really is.
From what I've gathered, it's a one-day event with a bunch of talks lined up.

Is there anything else? =P

[dragomirtitian]

@AnyhowStep that's usually what conferences are, bunch of talks, people talking, people networking, people plotting the overthrow of Javascript and its replacement with Typescript by violent revolution.... Um.. Have I said too much?

[jack-williams]

• Any chance we could get a pinned issue that points to all the canonical issues (or maybe the 10 most popular ones)?

• What's the status of the FAQ? Have we given up hope that anyone will actually read it?

  A suggestion borne out of optimism: if someone on the team spots a well written answer to a common problem maybe they could invite the author to polish it up, add it to the FAQ, and then have it tweeted by the TypeScript account as '_featured answer of the month_'.

[lppedd]

I would like to ask if there is any planned advancement on allowing custom Transformers via the tsc command, or via the tsconfig.json file.
Currently it seems trying to use them is like "hacking".

[gmurray81]

In light of the focus on more expressiveness in the type system, and the recent changes to setters/getters in type declarations, might I propose that this issue is given another look?

https://github.com/microsoft/TypeScript/issues/2521#issuecomment-526172422

I think improving this would allow for more accurate description of the actual types of existing JS libraries as they stand, not to mention the DOM's actual behavior.

[NickHeiner]

Types on every desk, in every home, for every JS developer

:heart:

[orta]

@jack-williams The FAQ is an interesting one, I wonder if it can be expanded into a section (with sub-sections) in the new site because that wiki page is redonqulously big. Happy to chat about ideas on an issue in the website if you've got ideas (otherwise I'll put it on my back burner to think about)

[jack-williams]

@orta Where should I move the discussion to? I don't know if I've got any good ideas, but maybe in the course of talking about it something will emerge.

[orta]

The website issues is a good spot for this https://github.com/microsoft/TypeScript-website/issues

[jack-williams]

Cheers! That's what I thought you meant, but I was being slow.

[MgSam]

Have you guys set a target release for optional chaining now that its reached Stage 3?

[orta]

You can follow the details in https://github.com/microsoft/TypeScript/issues/16 - which is scoped for 3.7 👍

The PR is here: https://github.com/microsoft/TypeScript/pull/33294

[Validark]

16 is going to change lives. The ?? operator is cool, but the ?. operator, even just the basic and most common form, is going to change lives. (conditionalPropertyAccess expressions?) I am so excited about it.

[falsandtru]

It is about time to support last arguments and elements #1360.

[DanielRosenwasser]

Technically the FAQ can be edited on https://github.com/Microsoft/TypeScript-wiki/

[asvishnyakov]

I hope I live to see that day when Typescript will have ?. operator

[xiaoxiangmoe]

What's protocols? Is this one?

[DanielRosenwasser]

@xiaoxiangmoe yes.

@asvishnyakov you still alive?

[Kingwl]

• Automating the addition of JSDoc types

Are there any existed issues? I'm very interested in this one.
https://github.com/microsoft/TypeScript/issues/10 i guess?

[dko-slapdash]

Add a tsc flag to translate import paths to relative ones in the compiler output, please! Thousands of developers are waiting for this feature and have to use fragile hacks through ttypescript/plugins or cheat with NODE_PATH env variable.

https://github.com/microsoft/TypeScript/issues/15479 - marked as “out of scope”, although it deserves one more look.

[asvishnyakov]

@DanielRosenwasser O MY GOD!

[AnyhowStep]

I found some Types on my desk

[fatcerberus]

@dko-slapdash Not likely to happen, unfortunately: https://github.com/microsoft/TypeScript/issues/31643#issuecomment-496995677

[pie6k]

Hello TS Team!

I appreciate your efforts to improve typescript performance! I'm very happy using TS, but as my project (react native) grew performance started to fall so badly, that it's the biggest factor impacting my productivity.

I have to reset TS server ~every 30 minutes (I'm using VS Code), quite frequently more often than that. Autocomplete with auto-import often works in a weird way - it properly suggests a variable name, but when I use it - it's not importing needed module. Sometimes I have to CMD+Space to see import suggestions, but sometimes it does not work and I have to manually write imports. Often autosuggestions start to work so slowly (3-10s) that it becomes unusable.

I'd like to help you by providing some feedback, but I actually don't know how to collect needed data. I've tried to enable verbose logs, but I'm getting a huge amount of logs (often more than 50mb) which includes so much noise, that I actually have no idea what is going on.

It would be very useful to have some sort of guide related to actually detecting and narrowing down issues with the ts server. It would be awesome to have some 'smart' diagnostics tool that would be able to tell something like 'this module types took 80% of time needed for suggestions collection caused by your last CMD+space'

I'm open to having some sessions with you trying to reproduce the issue. I don't have any specific scenario. Sometimes it works just fine for 2 hours after restarting TS server and sometimes I have to restart it every 10 minutes so I'm worried I'll waste your time if I'll not be able to reproduce it. If you're interested, however - I'd be more than happy to help as much as I can.

Screen Recording 2020-04-02 at 10.44.43 PM.mov.zip

I'm sending screen recording with issue - when I'm typing - it suggest proper variable name I can import, but when I use it - it's not actually imported. I have to CMD+Space at the end of it again to make VS Code suggest me to import given variable

[DanielRosenwasser]

Please don't file issues as comments on the roadmap, folks. It makes it significantly harder for us to manage the issue tracker.

Also, closing this as https://github.com/microsoft/TypeScript/issues/36948 is the current active roadmap.