Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
TypeScript Roadmap: January - June 2019 #29288
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. We may adjust over this period depending on changing needs and feedback from our users.
At a high-level, we're going to be focusing on the following 5 goals:
How do we plan to tackle this? While much of what we do ties into other domains, the how is broken down into the following sections which this roadmap will dive into:
Language design and innovation
TypeScript and the core type system
Something that may be surprising is "proving relationships between types". In a sense, this is our team generalizing patterns between type operators and encoding that in our type relationships. It's effectively having the compiler do algebra so that things "just work" when users use our type operators.
Whoever these users are, we believe TypeScript can serve them in some way.
We are involved in several different committees, including TC39 and the Node modules group. We try to provide representation as
Currently we're prioritizing forward compatibility with proposals/features that we've adopted early on, but we want to be involved in other above features both because we want to ensure that ECMAScript continues to grow in a way that makes developers' lives easier.
We have no plans to implement any proposals unless they hit stage 3 and we have high confidence in them.
Developer productivity tools and integration
More details here
Whereas many of our quick fixes are "reactive" (i.e. they are created and triggered after a user has seen a definite error), "proactive" fixes are a way of taking the experience a step further where TypeScript can analyze code and can surface suggestions and code changes for improvements rather than to fix an error. As an example, as of TypeScript 3.2, we can detect implicit `any` types even outside of `noImplicitAny` and offer up a fix to infer an appropriate type.
Beyond that, we have more targeted workflows in mind. A lot of our recent feedback around TypeScript has been that dealing with declaration files is still the most painful part of the workflow - specifically around adding declarations when they don't exist on DefinitelyTyped, and fixing erroneous declaration files. We want to investigate whether there's a good workflow we can provide here.
Meanwhile, ESLint already has the more-performant architecture we're looking for from a linter. Additionally, different communities of users often have lint rules (e.g. rules for React Hooks or Vue) that are built for ESLint, but not TSLint.
Given this, our editor team will be focusing on leveraging ESLint rather than duplicating work. For scenarios that ESLint currently doesn't cover (e.g. semantic linting or program-wide linting), we'll be working on sending contributions to bring ESLint's TypeScript support to parity with TSLint. As an initial testbed of how this works in practice, we'll be switching the TypeScript repository over to using ESLint, and sending any new rules upstream.
Speed, scalability, and stability
More details here
With composite projects, we introduced a "smarter" way to build co-located TypeScript projects for scenarios such as monorepos, "serverless" apps, etc. Part of the goal of composite projects was faster builds with seamless editor experience. We'll be continuing there, polishing the experience and making improvements like functionality for automatically swapping projects in and out to save memory.
Over the last few versions of TypeScript, we've also seen some emit-time regressions. We're going to be investigating what happened to cause this, which includes setting up infrastructure to track the regression and hunting down the original problem.
Command line experiences
We've consistently been asked for ways to automatically apply the sorts of code transformations that our quick fixes and refactorings use. Similarly, users have asked us for ways to trigger operations like "organize imports" or "format file" so that they can be used in pre-commit hooks. We want to investigate surfacing language service operations on the command line.
In the past, we've deferred to providing our users with APIs that they can consume. This has worked to some extent, encouraging users to create projects like tsfmt. In practice, we haven't seen that much of this.
Education and UX
More details here.
Over the next few months, we'll be working on a new version of handbook. Writing a general document for all users is difficult because the audience for TypeScript is broad, and one of the strengths (and weaknesses) of the current handbook is that it tries to serve everyone at once. We have several different groups of developers who have different expectations when learning TypeScript, and we need to adjust the level of exposure of different concepts. Given that, our goal is to organize the handbook into three different parts:
Our idea here is to segment developers and create a custom introduction to TypeScript for different groups. These buckets would include
Users who are looking for precise behavior and descriptions of TypeScript, on the other hand, will have a new section called "reference pages". These reference pages should have precise language and clear examples without impacting readability.
Error and type display UX
More details here
Error UX is a subtle but fundamental part of comprehending what the type system is doing. Over the past few years, TypeScript has accumulated what one could call "UX debt". As our type system has become more advanced, our UX hasn't kept up. To catch up, in the last 3 versions of TypeScript (3.0, 3.1, and 3.2) we worked on several different batches of error message improvements.
The community response has been overwhelmingly positive and has validated the original feedback we received from talking directly to users. As we try to serve more inexperienced users, we need to guide them to solutions quickly with precise but approachable error UX. This includes prioritizing misleading error messages that users file, and thinking deeply about what the heck is going wrong on the scarier messages. But it also opens up the opportunity for creative new ideas. For example, can we can have editors surface a more approachable experience, where users only see the full explanation of an error on demand.
Playground and website
In addition to the handbook, we need to make adjustments to the website. Our playground will need an update, and will need an update to the examples.
More details here
Today, DefinitelyTyped is the 10th most popular open source project on GitHub. That means there's a lot of traffic. When it comes to our team, we see our primary role not in authoring declaration files, but as building out the tools for others to do so. That includes our weekly PR rotations (where members of our team review external PRs to DefinitelyTyped) and DefinitelyTyped's surrounding infrastructure such as the types publisher, dtslint, and dt-mergebot.
As described in the productivity section of this document, we also have some ideas to make the offhand authoring process easier.
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!
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.
Everything that aids us in our day-to-day development and publishing processes around TypeScript is continuously valued. Making builds faster (e.g. converting our builds not to bootstrap themselves outside of CI), adding/migrating our lint rules, and adding new benchmarking infrastructure are things.
The idea here is really anything that improves
for development on the TypeScript project and any of our satellite projects.
@ajafff I don't think the first part was meant to suggest that, but I think that still falls under the rolling basis of requests from API consumers. Part of the concern there is the level of abstraction we can provide for consumers given the sorts of underlying optimizations we might use in the type system.
You probably don't have concrete plans to share yet, but I wonder whether you're planning on adopting
Currently in my work projects I still have to run both linters; eslint + prettier for nearly everything, and tslint for semantic rules like
PS: I also use tslint's
Thanks for the roadmap @DanielRosenwasser. Very informative.
We've been using @babel/preset-typescript to provide TypeScript support for our users of create-react-app and it has worked beautifully so far. Do you foresee any additional investment in the Babel ecosystem from your team with regards to this preset or otherwise?
Some more comments:
Also, it could be a good idea to rename "typescript playground" to something else; "typescript demo"? "typescript repl"? "typescript sandbox"? A google search for "ts playground" doesn't return what you were looking for (twitter reacts), at least as it relates to this project.
IMO the biggest drawback of TypeScript compared to Unity/C# is the lack of operator overloading, which is used like in every method, when you are dealing with vectors, matrices and quaternions. Could that be added to the list for the next 6 months? It would really give TypeScript an edge for all the game developers.
One problem I encountered a lot when I introduced modern JS in my codebase is people writing and exporting either singleton objects or classes that only have static members. This is due to people misunderstanding ES modules, and misunderstanding of ES modules is rampant in the JS/TS community.
I believe a contribution to it is how typescript implements star imports, and is self-perpetuating because of how many code samples and even
@kungfooman That's a TC39 / ECMAScript problem, not TypeScript, because it's a runtime feature. See Goals 3, 4, 6, 7 and 8 of https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals
@Kovensky I've been working to enable semantic rules for ESLint through
@Kovensky It just needs a little bit of AST rewriting, like
If thats already too much "breakage", it could be a tsc compiler option.
I feel surfacing the operations as API would be more worthwhile. For example, if I can get an easy-to-use API to get all unused variables in a codebase, get all usage of a specific library, etc, they would be immensely helpful for me to build other tools on top of it.
I doubt what people want is, say, running
would be really nice.
On the other hand, let's say TS offers an API for finding all usages of a specific library. Now I can generate dependency graphs or even automate code-splitting. I think making "CLI tool" the end goal would only capture very limited use cases.
That sounds great. And it would be nice, if one could automatically create pull requests from those
And also: PRs are always welcome!
Why: Palantir has deprecated tslint and typescript will be adopting eslint as well in future microsoft/TypeScript#29288 https://medium.com/palantir/tslint-in-2019-1a144c2317a9 https://eslint.org/blog/2019/01/future-typescript-eslint How: Added typescript eslint parser and other relevant packages
Hello. Has anyone publicly written about why TSLint’s architecture made it less performant than ESLint’s? It seems that most of the discussion about this happened privately between teams at Microsoft and Palantir. There is this mention on Palantir’s blog
I’m interested in this because I’ve been dabbling with the typescript compiler/language service API and I think a post-mortem for why TSLint was deprecated would be very informative for people using these APIs going forward.
@brainkim the TL;DR is that (many) TSLint rules are written in a way that require one "walk" of the tree per rule, whereas ESLint's programming model has rules participate in a shared walk. This is important because for a large program, the walking of the syntax tree itself can be quite expensive; for example it's around 100ms for our own codebase. If you're running e.g. 60 rules, that implies a bare minimum cost of 6 seconds before any actual checking happens.
I’m not the one who dug into the numbers but I’ll give the explanation a shot. TSLint’s model provides a single walk over a file’s abstract syntax tree (AST) for every lint rule, whereas ESLint’s uses a single walk because rules can register against node types that they’re interested in. A full walk of a file’s AST can be relatively slow, especially because nodes aren’t always allocated close to each other in memory (i.e. there’s no guarantee of memory locality). Given enough rules over enough files, this all becomes especially noticeable in TSLint thanks to multiple walks and a lot of potential cache invalidation. ESLint benefits from fewer traversals and memory locality between running different rules.