TypeScript Roadmap: January - December 2020 #36948
Comments
|
And yes, the fact that we're 3 weeks into February as I post this is embarrassing :D |
Do you mean something like this?? 😮 |
I have done a few PRs aimed at optimizing memory usage, and I have just blogged about how I discovered the latest such optimization in #36845 here: https://swatinem.de/blog/moar-ts-optimization/ Nice to see the TS team is interested in investing more into this, and I hope this helps to move things along. |
|
@DanielRosenwasser I remember that plugins were being discussed some time ago, but they aren't on the roadmap. Is it still something you plan to implement? (If not, is there something we can do to unblock this?) |
|
@DanielRosenwasser Any chance to see the updated roadmap on the wiki/roadmap page? It looks like a dead page... |
|
For the Handbook and Website section, I really hope that you will take a long look at all of the documentation issues. Especially Checking JavaScript Files.md is completely missing from the new Handbook. |
|
Looks like the concept from #35822 didn't make it into the roadmap. Can it be included for the next one? |
|
@treybrisbane @DanielRosenwasser Correct me if I'm wrong, but I assume these "local type declarations" would basically just be so we could avoid repeating ourselves in more complicated types. It'd be nice if this feature also could extend to type guards as well - that's where I could use it the most currently as I have a project with some very complicated type guards (as they're asserting invariants about them - conditional types would delay the errors to the call site and feature some unhelpful messages of "X is not assignable to never", obviously not ideal). |
|
great |
|
Uhhhhhh. Are there any new update of long-term plan? (After June) |
|
yeah,how?
|
|
I was just wondering about the plan for July - December 2020 as well. |
|
Is there any roadmap for January – June 2021? |
|
We're working on it and should have updates soon. We plan to switch to a year-long roadmap format FWIW |
DanielRosenwasser
changed the title
|
The way I am thinking about it right now is we plan with 6 months in mind and if nothing changes, we just rename it to a year-long roadmap, which is basically what happened in 2020. 😄 |
and others
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:
The how is broken down into the following sections:
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
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:
Promiseunwrapping on generic typesBack to top
JavaScript: TypeScript beyond TypeScript
TypeScript isn't just for TypeScript anymore. Our userbase now includes the JavaScript ecosystem as a whole, whether they are
.js/.jsxfiles in editors powered by TypeScript,allowJs,checkJs(also enabled by the// @ts-checkcomment), orWhoever these users are, we believe TypeScript can serve them in some way.
We largely expect investment in the following areas:
.d.tsfile generation from.jsfilesBack to top
Committee Representation
We are involved in several different committees, including TC39 and the Node modules group. We try to provide representation as
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
tsconfig.jsonfiles)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.jsonit can find walking up the chain of directories. That might be a problem in a codebase with multiple configuration files (e.g. atsconfig.jsonand atsconfig.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
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
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
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
--buildmode 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 usingtsc --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
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
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.tsfiles so that they can be consumed by older versions of TypeScript. For example, for Typescript 3.6,.d.tsfiles withgetaccessors in classes need to be rewritten to property declarations. This tool will need ongoing investment for each release containing new.d.tssyntax.Back to top
DefinitelyTyped
Back to top
External contributors
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
Back to top
Outreach
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
The idea here is really anything that improves
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
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
The text was updated successfully, but these errors were encountered: