GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing github.com — TypeScript Roadmap: January - December 2020 · Issue #36948 · microsoft/TypeScript Closed Labels PlanningIteration plans and roadmappingIteration plans and roadmapping DescriptionRoadmap OverviewThis 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 innovationTypeScript 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:
JavaScript: TypeScript beyond TypeScript
TypeScript isn't just for TypeScript anymore. Our userbase now includes the JavaScript ecosystem as a whole, whether they are
Whoever these users are, we believe TypeScript can serve them in some way. We largely expect investment in the following areas:
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 integrationEditor productivity
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 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. Linting
We've seen that there are areas for improvement in ESLint integration, both for JavaScript and TypeScript.
It's not clear exactly what has to improve, but we'll be keeping a watchful eye here. 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; One area we'll also be investing in will be parallelized 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. Education and UXHandbook 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. 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. Community investmentdownlevel-dtsdownlevel-dts is a tool that we've had requested many times over the past few years. It lets library authors rewrite DefinitelyTyped
External contributors
Partner teamsWe'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! API Consumers
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 engineeringTeam 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. 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. Reacted by Evan Henley, Daiki Ihara, Mohammed Sadiq, Raffael Campos, Diego Stratta, Luke, Alfonso Andrés López Molina, Braden Napier, Andrii Oriekhov, Kim and 6 more Reacted by Iván Pérez Reacted by Trey Brisbane, Sean Vieira, Huan Li, Christian, ahagelstein, Julius Bagdonas, developez, Bnaya Peretz, Dmitry Karpunin, Henning Hall and 25 more Reacted by Marko Kaznovac, Braden Napier, Abdallah Ebrahim and Will Slattum Activity
MetadataMetadataAssigneesLabelsPlanningIteration plans and roadmappingIteration plans and roadmapping TypeProjectsMilestoneRelationshipsDevelopmentIssue actions |
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |