René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"TypeScript Roadmap: January - June 2019","articleBody":"# \u003cspan id=\"roadmap-overview\"\u003e\u003c/span\u003eRoadmap Overview\r\n\r\nThis 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.\r\n\r\nAt a high-level, we're going to be focusing on the following 5 goals:\r\n\r\n* **Types** on every desk, in every home, for every JS developer\r\n* **Productivity** through strong tooling\r\n* **Approachability** and UX\r\n* **Community** engagement\r\n* **Infrastructure** and engineering systems\r\n\r\nHow 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:\r\n\r\n* [Language design and innovation](#language-design-and-innovation)\r\n* [Developer productivity tools and integration](#developer-productivity-tools-and-integration)\r\n* [Education and UX](#education-and-ux)\r\n* [Community investment](#community-investment)\r\n* [Internal engineering](#internal-engineering)\r\n\r\n# Language design and innovation\r\n\r\n## TypeScript and the core type system\r\n\r\n* Enabling popular JS patterns in a type-safe way\r\n* Increasing expressivity\r\n* Proving relationships between types\r\n* Stricter settings\r\n* Implementing ECMAScript features\r\n\r\nThis 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.\r\n\r\nSomething 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.\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## JavaScript: TypeScript beyond TypeScript\r\n\r\n* Understanding more dynamic patterns\r\n* Making the JavaScript editing experience better\r\n* Automating the addition of JSDoc types\r\n* Smoothing the transition to TypeScript\r\n\r\nTypeScript isn't just for TypeScript anymore. Our userbase now includes the JavaScript ecosystem as a whole, whether they are \r\n\r\n* using `.js`/`.jsx` files in editors powered by TypeScript,\r\n* compiling purely with `allowJs`.\r\n* type-checking with `checkJs` (also enabled by the `// @ts-check` comment), or\r\n* transitioning to TypeScript\r\n\r\nWhoever these users are, we believe TypeScript can serve them in some way.\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Committee representation\r\n\r\n* Class fields (public and private)\r\n* Decorators\r\n* ES/CJS module interop\r\n* Null propagation/coalescing\r\n* Pipeline\r\n* Protocols\r\n* Class static blocks\r\n\r\nWe are involved in several different committees, including TC39 and the Node modules group. We try to provide representation as\r\n\r\n* implementers of TypeScript, the type-checker\r\n* implementers of JavaScript language services \u0026 tooling\r\n* a voice for the users of both of the above\r\n\r\nCurrently 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.\r\n\r\nWe have no plans to implement any proposals unless they hit stage 3 and we have high confidence in them.\r\n\r\n# Developer productivity tools and integration\r\n\r\n## Editor productivity\r\n\r\n* \"Proactive\" quick fixes (i.e. suggestions)\r\n* Declaration file fixes and refactorings\r\n    * Generate missing `.d.ts` files\r\n    * Locally fork `@types` package\r\n* \"Bread and butter\" fixes \u0026 refactorings\r\n* Migration tooling\r\n\r\n\u003cdetails\u003e\r\n\u003csummary\u003e\r\nMore details here\r\n\u003c/summary\u003e\r\n\u003cp\u003e\r\nThese \"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. This functionality is also useful for teaching users about language features and patterns, and can make working with TypeScript/JavaScript more approachable.\r\n\u003c/p\u003e\r\n\u003cp\u003e\r\nWhereas 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.\r\n\u003c/p\u003e\r\n\u003cp\u003e\r\nBeyond 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.\r\n\u003c/p\u003e\r\n\u003cp\u003e\r\nAnother targeted workflow is migration. We'll be investing in ways to ease migration to TypeScript and typed JavaScript as we believe there is still work to be done here to smooth out the process of adding types.\r\n\u003c/p\u003e\r\n\u003c/details\u003e\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Linting\r\n\r\n* Semantic rules in ESLint\r\n    * Parity with TSLint\r\n    * Speed \u0026 scalability\r\n* Editor integration for ESLint\r\n\r\nIn a survey we ran in VS Code a few months back, the most frequent theme we heard from users was that the linting experience left much to be desired. Since part of our team is dedicated to editing experiences in JavaScript, our editor team set out to add support for both TSLint and ESLint. However, we noticed that there were a few architectural issues with the way TSLint rules operate that impacted performance. Fixing TSLint to operate more efficiently would require a different API which would break existing rules (unless an interop API was built like what [wotan](https://github.com/fimbullinter/wotan/) provides).\r\n\r\nMeanwhile, 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.\r\n\r\nGiven 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.\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Speed, scalability, and stability\r\n\r\n* Automatically unloading projects in TSServer\r\n* Composite project polish \u0026 fixes\r\n* Addressing performance issues\r\n    * ETW support\r\n    * Benchmarking infrastructure\r\n    * Tracking down and fixing regressions\r\n* Automated testing infrastructure for TSServer\r\n\r\n\u003cdetails\u003e\r\n\u003csummary\u003e\r\nMore details here\r\n\u003c/summary\u003e\r\n\u003cp\u003e\r\nWith 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.\r\n\u003c/p\u003e\r\n\u003cp\u003e\r\nIn part because JavaScript users typically lack any sort of project configuration, we have seen some poor performance (especially for users in Visual Studio), and as such we'll be making this a near-term priority.\r\n\u003c/p\u003e\r\n\u003cp\u003e\r\nOver 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.\r\n\u003c/p\u003e\r\n\u003c/details\u003e\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Command line experiences\r\n\r\nWe'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.\r\n\r\nIn 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](https://github.com/vvakame/typescript-formatter). In practice, we haven't seen that much of this.\r\n\r\nIn the meantime, we've seen projects like [Prettier](https://prettier.io/) and [jscodeshift](https://github.com/facebook/jscodeshift) sprout up, both with TypeScript support. These tools specialize specifically in their respective areas (formatting and code transformation), so we don't necessarily see ourselves as \"competing\" with these in any way; but if TypeScript drives the fundamental editing experience for TypeScript and JavaScript users, it feels like there's a gap to be filled between what happens in the editor and what happens during commits \u0026 CI, so we want to see what we can bring users here.\r\n\r\n# Education and UX\r\n\r\n## New handbook\r\n\r\n* Writing tailored intros for developers with different backgrounds\r\n* Writing new core handbook\r\n* Reference pages\r\n* Infrastructure to replace look \u0026 feel, and subsume current publishing process\r\n* Documentation around `checkJs`\r\n\r\n\u003cdetails\u003e\r\n\u003csummary\u003e\r\nMore details here.\r\n\u003c/summary\u003e\r\n\r\nWe've long had a comprehension and perception problem from our handbook. If you look at our documentation today, union types come way too late in handbook under a section called \"advanced types\". It also [assumes too much about terminology](https://twitter.com/ryanflorence/status/1057093786428432384). Additionally, TypeScript is often perceived as a language that pushes JavaScript developers to write object-oriented code, and we suspect this is because our documentation and examples focused on newer ECMAScript features like classes (partially to demonstrate down-leveling features, and partially because we lacked union types early on). We're overdue for some changes.\r\n\r\nOver 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:\r\n\r\n1. Tailored introductions (setup for the core handbook)\r\n2. The core handbook (everyone reads this)\r\n3. Reference pages (kind of like deep-dives/appendices)\r\n\r\n![](https://i.imgur.com/WL1KUh9.png)\r\n\r\nOur idea here is to segment developers and create a custom introduction to TypeScript for different groups. These buckets would include\r\n\r\n* Complete novices\r\n* Background mainly in JS (or another dynamically-typed language)\r\n* Background mainly in statically-typed OO languages\r\n* Background mainly in statically-typed FP languages\r\n* Background with many different languages (i.e. the \"veteran\" developers)\r\n\r\nOnce developers get past the intros, they are directed to the core handbook. The core handbook makes no assumptions about other languages, just a reasonably comfortable understanding of JavaScript. Users who read through the documentation of the handbook should never feel overwhelmed by details (the tone of the core handbook should be informal), and should be able to dive into most TypeScript codebases and feel comfortable contributing.\r\n\r\nUsers 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.\r\n\u003c/details\u003e\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Error and type display UX\r\n\r\n* Interactive diagnostics and quick info\r\n* \"Smarter\" diagnostics\r\n* More related error spans\r\n\r\n\u003cdetails\u003e\r\n\u003csummary\u003e\r\nMore details here\r\n\u003c/summary\u003e\r\n\r\nError 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.\r\n\r\n![](https://msdnshared.blob.core.windows.net/media/2018/07/3.0-error-messages-object-literals-vertical-2.png)\r\n\r\nThe 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](https://twitter.com/michlbrmly/status/1066013071251070977) 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.\r\n\u003c/details\u003e\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Playground and website\r\n\r\n* Update examples to less OO-heavy/ESNext style\r\n* Playground\r\n    * Editable `tsconfig.json`\r\n    * Serialized playground settings\r\n    * Nightly playground releases via CDNs\r\n\r\nIn 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.\r\n\r\n# Community investment\r\n\r\n## DefinitelyTyped\r\n\r\n* Weekly DefinitelyTyped rotations\r\n* Surrounding infrastructure\r\n    * [types-publisher](https://github.com/Microsoft/types-publisher)\r\n    * [dt-mergebot](https://github.com/RyanCavanaugh/dt-mergebot)\r\n    * [dtslint](https://github.com/Microsoft/dtslint)\r\n\r\n\u003cdetails\u003e\r\n\u003csummary\u003e\r\nMore details here\r\n\u003c/summary\u003e\r\n\u003cp\u003e\r\nDefinitelyTyped is now such a core part of the JavaScript and TypeScript ecosystem. First and foremost, it's what actually lets TypeScript users interoperate smoothly with JavaScript libraries. But beyond that, it now powers the JavaScript editing experience across several different editors.\r\n\u003c/p\u003e\r\n\u003cp\u003e\r\nToday, \u003ca href=\"https://octoverse.github.com/projects#languages\"\u003eDefinitelyTyped is the 10th most popular open source project on GitHub\u003c/a\u003e. 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 \u003ca href=\"https://github.com/Microsoft/types-publisher\"\u003etypes publisher\u003c/a\u003e, \u003ca href=\"https://github.com/Microsoft/dtslint/\"\u003edtslint\u003c/a\u003e, and \u003ca href=\"https://github.com/RyanCavanaugh/dt-mergebot/\"\u003edt-mergebot\u003c/a\u003e.\r\n\u003c/p\u003e\r\n\u003cp\u003e\r\nAs described in the productivity section of this document, we also have some ideas to make the offhand authoring process easier.\r\n\u003c/p\u003e\r\n\u003c/details\u003e\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## External contributors\r\n\r\n* Easier contributions to the docs\r\n* Open contributions to the playground and website\r\n* Automated PR process on TypeScript\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Partner teams\r\n\r\nWe 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!\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## API Consumers\r\n\r\n* Rolling requests for API endpoints\r\n* Investigate improving rich editing experiences\r\n    * in enhancing plugins like IntelliCode\r\n    * in templates\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Outreach\r\n\r\n* Public talks\r\n* Meetup attendance\r\n* In-depth blog post content\r\n* Help with TSConf coordination\r\n\r\nWe 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.\r\n\r\n# Internal engineering\r\n\r\n## Team infrastructure\r\n\r\n* Faster builds\r\n    * Always use the LKG to build the compiler.\r\n* Better testing across external repositories\r\n\r\nEverything 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.\r\n\r\nThe idea here is really anything that improves\r\n\r\n* stability\r\n* productivity\r\n* ease of contribution\r\n\r\nfor development on the TypeScript project and any of our satellite projects.\r\n\r\n[**Back to top**](#roadmap-overview)\r\n\r\n## Organizational guidance\r\n\r\n* Internal guidance on TypeScript-first API designs\r\n* Providing internal partner teams with best practices for projects\r\n* Addressing major Microsoft-internal build regressions\r\n\r\nBecause 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.\r\n\r\n[**Back to top**](#roadmap-overview)","author":{"url":"https://github.com/DanielRosenwasser","@type":"Person","name":"DanielRosenwasser"},"datePublished":"2019-01-07T18:37:17.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":103},"url":"https://github.com/29288/TypeScript/issues/29288"}