TypeScript Roadmap: January - June 2019
DanielRosenwasser opened this issue · 103 comments
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. 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:
- Types on every desk, in every home, for every JS developer
- Productivity through strong tooling
- Approachability and UX
- Community engagement
- Infrastructure and engineering systems
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
- Developer productivity tools and integration
- Education and UX
- Community investment
- Internal engineering
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.
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.
JavaScript: TypeScript beyond TypeScript
- Understanding more dynamic patterns
- Making the JavaScript editing experience better
- Automating the addition of JSDoc types
- Smoothing the transition to TypeScript
TypeScript isn't just for TypeScript anymore. Our userbase now includes the JavaScript ecosystem as a whole, whether they are
- using
.js/.jsxfiles in editors powered by TypeScript, - compiling purely with
allowJs. - type-checking with
checkJs(also enabled by the// @ts-checkcomment), or - transitioning to TypeScript
Whoever these users are, we believe TypeScript can serve them in some way.
Committee representation
- Class fields (public and private)
- Decorators
- ES/CJS module interop
- Null propagation/coalescing
- Pipeline
- Protocols
- Class static blocks
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
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
Editor productivity
- "Proactive" quick fixes (i.e. suggestions)
- Declaration file fixes and refactorings
- Generate missing
.d.tsfiles - Locally fork
@typespackage
- Generate missing
- "Bread and butter" fixes & refactorings
- Migration tooling
More details here
These "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.
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.
Another 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.
Linting
- Semantic rules in ESLint
- Parity with TSLint
- Speed & scalability
- Editor integration for ESLint
In 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 provides).
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
- Automatically unloading projects in TSServer
- Composite project polish & fixes
- Addressing performance issues
- ETW support
- Benchmarking infrastructure
- Tracking down and fixing regressions
- Automated testing infrastructure for TSServer
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.
In 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.
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.
In the meantime, we've seen projects like Prettier and 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 & CI, so we want to see what we can bring users here.
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.
We'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. 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.
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:
- Tailored introductions (setup for the core handbook)
- The core handbook (everyone reads this)
- Reference pages (kind of like deep-dives/appendices)
Our idea here is to segment developers and create a custom introduction to TypeScript for different groups. These buckets would include
- Complete novices
- Background mainly in JS (or another dynamically-typed language)
- Background mainly in statically-typed OO languages
- Background mainly in statically-typed FP languages
- Background with many different languages (i.e. the "veteran" developers)
Once 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.
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
- Interactive diagnostics and quick info
- "Smarter" diagnostics
- More related error spans
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
- Update examples to less OO-heavy/ESNext style
- Playground
- Editable
tsconfig.json - Serialized playground settings
- Nightly playground releases via CDNs
- Editable
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.
Community investment
DefinitelyTyped
- Weekly DefinitelyTyped rotations
- Surrounding infrastructure
More details here
DefinitelyTyped 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.
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.
External contributors
- Easier contributions to the docs
- Open contributions to the playground and website
- Automated PR process on TypeScript
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!
API Consumers
- Rolling requests for API endpoints
- Investigate improving rich editing experiences
- in enhancing plugins like IntelliCode
- in templates
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
- Always use the LKG to build the compiler.
- Better testing across external repositories
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
- stability
- productivity
- ease of contribution
for development on the TypeScript project and any of our satellite projects.
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.
Last time I checked, we live on 2019.
@j-oliveras it's still January, give me a break. 😃
I have a dream:
"In a world where we finally can maintain/generate types in a project with just .js files. In a world where Salsa is for everyone and typescript power can live inside of any JS project!"
Just finish this issue #7546 and make this dream come true!
Proving relationships between types
Developer productivity tools and integration
Does this mean you are finally exposing type relationship APIs so that tools can leverage the whole power of the type system?
@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.
Wow, thanks for vindicating my migration to eslint + 🎉typescript-eslint-parser a few months ago
You probably don't have concrete plans to share yet, but I wonder whether you're planning on adopting typescript-estree + typescript-eslint-parser or if you're going to provide something else entirely.
Currently in my work projects I still have to run both linters; eslint + prettier for nearly everything, and tslint for semantic rules like no-floating-promises, no-unnecessary-type-assertion, strict-type-predicates and deprecation.
PS: I also use tslint's ordered-imports as eslint's similarly-named sort-imports and imports/sort do something else entirely, but that probably doesn't fall under the scope of your project
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:
- What is "ETW support"; event tracing for windows?
- This is one thing that probably falls under personal preference, but it'd be greatly appreciated if the new docs wouldn't introduce
asas an "alternate syntax" to<assert>and never mentioned again, butasas the only syntax and the<assert>as a kind of "annex b" legacy feature. - This probably falls under DT governance instead of the TypeScript project itself, but I really want to completely rewrite
@types/reactin a breaking way (years of accumulated misfeatures and legacy baggage) and I don't know how I could do it without creating a python3 problem. I probably need some help here. - Babel's typescript parser unfortunately hasn't kept up with new syntax features in tsc; it's still stuck in typescript 2.8 level support. I started a PR to add
import()types support at least, but parsers are not my area of expertise...
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.
" 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 "...
The above is partially true but IMO is that there are lots of people coming from OOP background and other languages that enforce OOP and a lack of understanding JavaScript language. I remember before JS "classes" I would find myself explaining to other devs why you don't need the C word in JS and they would call me heretic an curse the language :)
Another thing is I don't think that many people leverage the idea of Union types which is one of the most powerful thing that TS has but this idea is not well understood by OOP devs but by FPers mostly
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.
The above is partially true but IMO is that there are lots of people coming from OOP background and other languages that enforce OOP and a lack of understanding JavaScript language.
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 @types packages (ab)use them for importing commonjs modules. Another unpopular "it's breaking but it's a good break" change I wish for, the --esModuleInterop behavior should be made true by default. Stop import { Component } from 'react'.
@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 typescript-estree and typescript-eslint-parser. Once eslint/typescript-eslint-parser#568 is in, we'll be able to merge the first few semantic rules to eslint-plugin-typescript and more in the future.
@Kovensky It just needs a little bit of AST rewriting, like vector_a * vector_b would emit the JavaScript code vector_a.mul(vector_b).
If thats already too much "breakage", it could be a tsc compiler option.
Once JavaScript finally supports operator overloading, TypeScript would already be prepared to make use of it.
@uniqueiniquity hmm, you have to manually specify path to tsconfig.json in the eslint config 😢
Would be nice to be able to resolve it relative to the file being linted, or at least relative to the eslint config instead of relative to cwd.
hm interesting @kungfooman — with TS’s type system, you can know which variables have overloaded operators, although anys would wreak havoc.
Please reconsider index (brackets []) operator type safety: #13778 (comment) — this operator is one of the core features of JavaScript and subsequently TypeScript but its usage is still not safe.
Didn't see it mentioned in the list but a rewrite of the JSX/TSX layer and all it's edge cases would be great. Having everything typed as JSX.Element is also quite annoying, when the props shape should be inferred and used. I believe this PR covers a bit of it: #21699
While probably largely outside the scope of TypeScript itself, I would love to see better webpack support (easy setup, fast recompiles, better sourcemap mapping, much better vscode problem matching support, etc)
surfacing language service operations on the command line.
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 tsc --autofix-all-my-unused-variable-errors my-project on CLI / CI. An API that allows people to:
- Get a list of diagnostic errors and autofixes
- Plug in their own custom logics. For example, only fix this error in
src/frontendbut notsrc/backend, exclude any file that ends withtest.ts, skip for variables of certain names. - Selectively run a part of the autofixes
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.
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.
That's likely due to lack of documentation and working samples. I'd love more projects similar to https://github.com/dsherret/ts-simple-ast and https://github.com/dsherret/ts-ast-viewer from TS team.
I am looking much forward to "Writing tailored intros for developers with different backgrounds"!
- Locally fork
@typespackage
That sounds great. And it would be nice, if one could automatically create pull requests from those 😍
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.
Oh, yes ❤️See you "remove unused vars"!
While probably largely outside the scope of TypeScript itself, I would love to see better webpack support (easy setup, fast recompiles, better sourcemap mapping, much better vscode problem matching support, etc)
@eamodio - speaking on behalf of ts-loader and fork-ts-checker-webpack-plugin I second this 😉
And also: PRs are always welcome!
@DanielRosenwasser happy new year 🎉 About the "New handbook" and "In-depth blog post content" I would be happy to try to contribute if you guys have a list of topics that you would like to cover.
I’d like to see an option to treat all TS files as TSX.
This is awesome, Great work!
In regard to "Enabling popular JS patterns in a type-safe way"...
I would like to draw some attention back to #2491.
This is a popular pattern and logically, a const enum gets compiled to a number.
Even after many duplicates tickets this is still not fixed.
const enum Filter {
One,
Two,
Three,
}
const filters: { [key: Filter]: string } = {};Please consider re-opening #2491
@styfle If I understand correctly what you want, you can already do it:
const enum Filter {
One, // If you want that start with 1 assign it
Two,
Three,
}
const filters1: { [key in Filter]: string } = { 0: '', 1: '', 2: '' };
const filters2: { [key in Filter]: string } = { [Filter.One]: '', [Filter.Two]: '', [Filter.Three]: '' };
const filters3: { [key in Filter]?: string } = {} // All optionals.@DanielRosenwasser Can you email me: eanderson@CompanyThatMaintainsTslint?
@kungfooman Typescript definitely shouldn't add operator overloading. As this roadmap says:
We have no plans to implement any proposals unless they hit stage 3 and we have high confidence in them.
As far as I can tell, operator overloading isn't even stage-0.
If you really want operator overloading in TS, you'd probably have more luck finding or writing a Babel plugin, and using a Babel 7 + Typescript setup to enable it in your projects.
@Kovensky My original approach actually did resolve the tsconfig path more implicitly, but I got some early feedback that led me to take the manual specification approach. It's certainly something I'm open to lighting up in the future though, since it should be fairly easy to add.
@DanielRosenwasser I would be happy to donate the code from https://typescript-play.js.org/. Or help with improving yours as soon as you open source it.
@agentcooper we actually might take you up on that offer. ❤️
I’d like to see an option to treat all TS files as TSX.
@j-f1 Won't happen because of parsing ambiguity issues, which is why .tsx exists in the first place.
While probably largely outside the scope of TypeScript itself, I would love to see better webpack support (easy setup, fast recompiles, better sourcemap mapping, much better vscode problem matching support, etc)
@eamodio @johnnyreilly if you have something only TypeScript can do, or which all API consumers would benefit from, let us know!
is that mean..... dependent type? or algebra data type?
@Kingwl it's more like scaffolding out type relationships so things you intuitively think make sense just work. For example, keyof T being a subtype of keyof U when U is a subtype of T, and both are generic.
@Kovensky
What is "ETW support"; event tracing for windows?
Yes, we might have a way for users to give more detailed reports of regressions using ETW (which is especially helpful for Visual Studio users who experience regressions, but can be used by anyone on Windows). I don't have exact design details, but it'll be installable as a separate module.
This is one thing that probably falls under personal preference, but it'd be greatly appreciated if the new docs wouldn't introduce
asas an "alternate syntax" to<assert>and never mentioned again, butasas the only syntax and the<assert>as a kind of "annex b" legacy feature.
Noted, and I have a strong preference for as as well.
This probably falls under DT governance instead of the TypeScript project itself, but I really want to completely rewrite
@types/reactin a breaking way (years of accumulated misfeatures and legacy baggage) and I don't know how I could do it without creating a python3 problem. I probably need some help here.
If you create an issue and include me, @weswigham, @RyanCavanaugh, and other interested authors in DefinitelyTyped, that might be a good first step, but I would urge caution here. That might end up being surprisingly disruptive.
Babel's typescript parser unfortunately hasn't kept up with new syntax features in tsc; it's still stuck in typescript 2.8 level support. I started a PR to add
import()types support at least, but parsers are not my area of expertise...
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?
@Kovensky @ianschmitz we've integrated Babel work into our Release Activities processes, so I guess it's implied. To my knowledge, import() types are the only TypeScript-specific feature from 2.9+ that's missing (see babel/babel#7747 and other issues filed on Babel under area: TypeScript). Looks like babel/babel#9302 is currently out for review though.
parsing ambiguity
That’s why I suggested an option — people who don’t need the ambiguous syntax can avoid having to name their files .tsx.
That’s why I suggested an option — people who don’t need the ambiguous syntax can avoid having to name their files
.tsx.
Check out #26489 where this was discussed last.
As far as I can tell, operator overloading isn't even stage-0.
@Retsam The operator overloading proposal is going to be advanced to stage-0 in Jan. 2019's TC39 meeting.
Although the conclusion is same, it's still far from stage-3.
Note: Advancing to stage-0 has no real requirement and always success.
All conversation around operator overloading should continue at #5407
yes I am aware that is a locked issue, we are not doing operator overloading
What I want to see is TypeScript to simply become a Babel plugin. Since v7 it understands TS syntax. I think this way TS would be able to fit much better in the whole ecosystem and the TS team can concentrate more on features than implementing EcmaScript transpilers which is done by Babel also anyway.
This is an extremely well written roadmap, well done!
You mentioned prettier in your roadmap, as the co-creator of prettier and the one actively pushing for TypeScript support, let me know if I can do anything to help or chat about the space, would love to.
Be great to see a playground that had functionality like a Jupyter Notebook. To actually run code in the existing playground is pretty cumbersome by comparison.
functionality like a Jupyter Notebook
You could partner with Observable to add TS support.
Is there much of a push to bring features to editors other than VSCode?
Some of the mentioned things like exposing new APIs, and New CLI tools would help third parties, but it would be great to see other editors (eg; vim edit: or emacs!) get official support.
Some of the mentioned things like exposing new APIs, and New CLI tools would help third parties, but it would be great to see other editors (eg; vim) get official support.
@sandersn is an avid emacs user 😄
I'm very sad and disappointed that, despite wide community support and popular proposals, a better syntax for typing destructuring is not planned, for what seems like nebulous and speculative concerns, and instead we are getting half-baked answers like named parameter refactoring.
There is so much emphasis on making TypeScript a pleasant language to use in so many ways, I don't understand why such an ugly and frustrating language deficiency is allowed to persist when there is a good solution sitting in plain sight.
@jonrimmer that refactoring and that feature request are not at odds with each other. That refactoring is not an answer to easier typed object destructuring, and if a new syntax was adopted, then the refactoring itself could support both the proposed named as well as an anonymous version.
I don't understand why such an ugly and frustrating language deficiency is allowed to persist when there is a good solution sitting in plain sight.
Check our the original rationale.
Is there much of a push to bring features to editors other than VSCode?
@jesstelford we officially maintain TypeScript support for Visual Studio, Visual Studio Code, and our Sublime Text Plugin. Unfortunately while occasionally Nathan can send PRs to tide, we can't commit to taking care of all of these plugins.
On the other hand, we're more than happy to help support the authors of those plugins by answering API questions.
@DanielRosenwasser They may not exactly be at odds, but it's half-baked in that it's based on automating an ugly practice—cluttering codebases with separate, single-use interfaces that only serve to define the types for a function's signature—that wouldn't be necessary if we had a better syntax.
And I have read that rationale. That's what I was referring to as nebulous and speculative.
-
Concerns with ECMAScript's original use
:vsasas a renaming operator, valid or not, don't seem relevant. It is what it is, and it shouldn't curtail the useful improvement of TypeScript. -
Concerns about TC39 changing the rename syntax or overloading
asare speculative. Given the importance of TypeScript in the ECMAScript ecosystem, it seems highly unlikely that they would unilaterally make a change that broke a TS feature. There are also alternative proposals avoidingasin favour of:, but these have received no apparent discussion or feedback. -
Concerns about "added complexity" are nebulous and unanswerable, since they just restate generally unarguable design principles without specific or measurable relation to the proposal(s) at issue. While the proposed syntax is more complex than destructuring alone, it is less verbose and less error-prone that destructuring with separate interfaces/inline adjacent object types, as is currently required.
It's hard to escape the impression that the original decision was taken based on a reflexive dislike for an unavoidably imperfect syntax, and the rationale was mostly come up with post hoc. And the team thereafter adopted a close-minded attitude that this issue was settled and we should all forget about it. Except I can't forget about it, because I'm reminded each and every time I have to write some ugly and long-winded function definition.
@DanielRosenwasser love the commitment to 3rd party support, thanks!
A small feature request: it would be nice to edit source code as Typescript, but store it as .js + .d.ts, without losing types between sessions.
@jonrimmer it's not so black and white, whether the interfaces are single-use and clutter the code base or not.
You may refer to my comment here for my opinion
Just a few things on community investment.
Feature Suggestions
I pinged @DanielRosenwasser about this on another thread, but this thread seems far more appropriate. If there are design principles that the team evaluates features against internally, I would like to see these principles pushed publicly. This might include modifying the feature suggestion template, and even requiring authors to evaluate their features against these principles.
I'm aware that the feature template has guidelines and goals, but most are binary satisfies/does not satisfy. In particular, my suggestion is really aimed at this one point:
Produce a language that is composable and easy to reason about.
This is less a goal and more the holy grail of language design; what would be great is some more guidance towards satisfying this goal, as the TS team see the problem.
I think this has multiple benefits such as:
- Anyone that writes a feature proposal wants their feature to be adopted; using the language and metrics of the team will improve the likelihood a feature gains traction.
- It makes it easier for someone on the team to quickly evaluate a feature because the goals are explicit and evaluated in the feature suggestion.
- The TS team has a large amount of excellent programming language design experience. Any opportunity to collectively mine their brains for knowledge should be jumped at. If there are clear design goals, then it is easier to provide clear design feedback.
The Spec
Yes: I've said the dreaded 'S' word. I'm not proposing a return of the full spec; what I think would be great is to see new types and the type relationships properly spec'd out. The PR's that include the new types do include spec like documentation, but I would like to see a common style in a single document. Some justifications of this include:
- The current solution seems to a combination of the handbook, release notes, and the source code. The handbook is not sufficiently detailed to really understand the details of any advanced type (how many people still get tripped up on
nevershort-circuiting and distribution in conditional types). The source code is the ground truth, but is generally difficult for anyone new to the language to navigate. Without a detailed spec, you are excluding feedback from individuals capable of understanding advanced programming language semantics, but do not have knowledge of the compiler's internals. - With a spec comes a common language for talking about types and technical topics. I think this would improve community interaction by reducing ambiguity in discussion.
- As someone that tries to answer questions on the tracker, it would make my life easier if I could cite something in the spec that explains the issue, rather than typing it out. PR's that introduce the feature are not ideal because the features update; finding the latest behaviour can be tricky.
I would be happy to contribute to this, or the new handbook.
I think this issue deserves a reference in the official blog
@AnyhowStep I've read it. But you can do typesafe function wrapping without needing to break the params out as a separate interface using typeof and Parameters<T>:
// original
function foo(a: string, b: number): string {
return a + b;
}
// simple wrap
const bar: typeof foo = (a, b) => {
return foo(a, b) + 'bar';
};
// change the return type
const buzz: (...params: Parameters<typeof foo>) => void = (a, b) => {
console.log(foo(a, b));
}This will get even easier when #26017 lands.
When there is already all this great capability for working with the types of inline parameters, it seems so obvious to go that next step and add a better syntax for typing named parameters.
Your approach fails for generic functions,
// original
function foo<T extends string>(a: T, b: T|number): string {
return a + b;
}
// change the return type
const buzz: <T extends string>(...params: Parameters<typeof foo/*<T> We can't do this*/>) => void = (a, b) => {
console.log(foo(a, b));
}
buzz<"test">("not-supposed-to-work", 23);True, seems like #29043 would need to be added to make typeof aware of generics.
Oh boy, am I excited!
"Types on every desk, in every home, for every JS developer"
I still cannot find anything about proper support for iterators (return type), is that not on the roadmap at all?
Setting up a new project with nontrivial layout is still a pain. Config files really need better documentation.
Setting up any project is a pain, wether it's TS or not. That's why I created the tool https://mhy.js.org (sorry for the ad, but it's kinda relevant). With it I don't need anything to setup to use TS and even if I need changes in the config, I can simply customize it. I'm not using tsc to compile my code anymore tho.
Re: DefinitelyTyped, honestly my biggest hurdle is Sorry, we had to truncate this directory to 1,000 files. 4,599 entries were omitted from the list.
Just FYI in case people are following along for the linting aspect
(i.e. an update to #29288 (comment) and #29288 (comment))
We now have https://typescript-eslint.io which the TypeScript Team are collaborating with us on.
I am hoping that includes support of very popular ecosystems. Some of the tricks necessary to handle typing of complex functions are truly overwhelming for newer developers. As an example: the JS code for a React HOC is quite simple. Typing it though...a little trip to hell to write and read.
export function withLogging<P extends LoggerProps>(
Component: React.ComponentType<P>
) {
return function ComponentWithLogging(
props: Pick<P, Exclude<keyof P, keyof LoggerProps>>
) {
return (
<LoggingContext.Consumer>
{(logger) => <Component {...props} logger={logger} />}
</LoggingContext.Consumer>
);
};
}The most annoying part is, that's still not correct. It doesn't account / loses the LibraryManagedAttributes, and it acts as if it passes refs through but it doesn't. It's... not easy. We need to think of better primitives.
It's striking to me how much of the TypeScript roadmap has nothing to do with the language itself.
I've started using TS recently, a few months ago, and I really like it. Today I use it for every JS project.
I don't know if there's already something available in TS or if I'm saying no sense things, but I would like to have TS closer to functional programming, not only tight to OOP.
Is it possible in the future to have something like pattern matching, own map, filter and other monads/functors without having to install thirty party library ?
Hey @DanielRosenwasser! Thanks for the detailed breakdown and feedback on suggestions/questions.
Regarding:
Enabling popular JS patterns in a type-safe way
In spite of all of its advancements, TS is still pretty deficient when it comes to common functional programming patterns, once you step outside the most basic use cases. For example, there's no general solution for currying with generics: they get erased to {}. This impacts any kind of higher-order composition including proper typing of HOCs in React.
#24626 has been hanging out for a while with lots of community interest, but little in the way of an official response. I appreciate that it's a hard problem, but it's even harder to want to put forth the effort to contribute when there's no way to know if your work will be accepted.
Some proactive guidance from the core team around acceptance criteria for this and related work would go a long way. Thanks again for your time.
In spite of all of its advancements, TS is still pretty deficient when it comes to common functional programming patterns, once you step outside the most basic use cases. For example, there's no general solution for currying with generics: they get erased to
{}. This impacts any kind of higher-order composition including proper typing of HOCs in React.
@nateabele I can't give a holistic response at the moment and I personally haven't evaluated that one, but you can see that this comes up periodically in design meetings.
#24626 has been hanging out for a while with lots of community interest, but little in the way of an official response. I appreciate that it's a hard problem, but it's even harder to want to put forth the effort to contribute when there's no way to know if your work will be accepted.
You are right and that's not fair to contributors. We're going to try to do better here. Maybe @RyanCavanaugh and @ahejlsberg can comment on that PR with the specific status, or we can raise it at a design meeting.
It's striking to me how much of the TypeScript roadmap has nothing to do with the language itself.
@MgSam the first section is entirely about the language, but
- I don't know what to say about working on the language that isn't "obvious", so I didn't elaborate much there.
- The truth is that the biggest needs of the TypeScript community (as well as the needs of the JavaScript community that TypeScript can serve) are not strictly limited to the language.
Is it possible in the future to have something like pattern matching, own map, filter and other monads/functors without having to install thirty party library ?
@ovidius72 we don't provide runtime libraries for functionality, and supporting higher kinded types in an ergonomic way in a structural type system doesn't seem to be a straightforward concept. There are other issues on the issue tracker where this is discussed.
@ovidius72 we don't provide runtime libraries for functionality, and supporting higher kinded types in an ergonomic way in a structural type system doesn't seem to be a straightforward concept. There are other issues on the issue tracker where this is discussed.
Are there plans to provide better support for implementing these things in userland?
I don't foresee any focus on that in the near future.
[T]his comes up periodically in design meetings.
@DanielRosenwasser Thanks for the quick response! Yeah, I did notice that. 😄 Definitely helps to know.
You are right and that's not fair to contributors. We're going to try to do better here.
I appreciate you acknowledging that, but I also appreciate that the surface area for a project like this is massive, and there are only so many core team members. If there are ways the community can engage with you that streamline your work, by all means, let us know!
Side note, I'd love to see Typescript get experimental support for Pipeline operator, since Babel already supports it. https://babeljs.io/blog/2018/07/19/whats-happening-with-the-pipeline-proposal
Side note, I'd love to see Typescript get experimental support for Pipeline operator since Babel already supports it. https://babeljs.io/blog/2018/07/19/whats-happening-with-the-pipeline-proposal
In my opinion, it is a bad idea to do it now; there are two competing proposals under consideration.
https://github.com/tc39/proposal-pipeline-operator
If engineers implement another syntax, it will be syntax-zoo.
Babel is working with minimal syntax only, not production ready.
@fnpen why not adopt Babel's rationale then for TypeScript, which would be fine to me: to adopt the minimal syntax under either a warning or feature flag that it's not recommended for production. By not exposing major new standards in their early stages to the TS community, the exposure is reduced for those who might have experimented and participate in conversation around the new proposal.
IMO, the community is better served by the TS team focusing on the core mission of Typescript (the typings), and leave the experimental syntax stuff in babel-land - (where it's part of their core mission). I think that's both a better use of development time, and for avoiding the "syntax zoo" issue fnpen mentioned.
If TS users want to play with experimental syntax, it should be possible to write a TS-aware babel plugin and use it in a babel7 + TS setup, that compiles down to standard TS syntax.
I would really like to see better support for the paths compiler option. It works great when I am in my editor. Attempting to execute the code, via ts-node or transpiling via tsc and then running the output is an exercise in frustration. I am plagued by issues of the module not being able to be found. (To be clear I am doing this all using node which means my moduleResolution is "node".) The only way I have been able to work around these annoyances is by a combination of modules tsconfig-paths and module-alias. I shouldn't have to use either of these to be able to easily compile and run my code in development/production mode. Please do something about this tooling travesty!
@jloveridge You may want to look into making a monorepo with multiple packages and using yarn workspaces or lerna. This way you can avoid tsconfig paths altogether and just use regular node resolution (since yarn workspaces/lerna creates symlinks in node_modules node). See this comment for some more info. If you are using the tsconfig-paths package and you are using webpack you may want to may want to look into using tsconfig-paths-webpack-plugin.
Another interesting option is to use yarn pnp which runs node with a plugin to by-pass regular module resolution. I have not tried this myself yet but it seems promising.
Hope that in "Enabling popular JS patterns in a type-safe way" is included the pattern for generator/saga.
@jonaskello I will look into it again. In the past a monorepo seemed like it would be more trouble than it was worth but perhaps the tooling is better now. I believe the guys working on the frontend are using webpack already and I know they are able to use paths without incident in their vue controllers and such but I don't know exactly the method being used to roll everything together.
@jloveridge Just on monday I gave a presentation with an overview of how to manage modern monorepos: https://jesstelford.github.io/talk-modern-js-monorepos
tl;dr: The tooling is getting better, and the pros outweigh the cons, but it's still not perfect.
* Making the JavaScript editing experience better
Boy, I hope this includes #25590
just published remove-tslint-comment, to help switching from tslint to eslint.
Are there any plans to ever replace var, let, and const, instead of adding the type definitions in addition to those?
Something like number size = 3.04.
And how the variable would act? As a const, let or var?
Another thing is I don't think that many people leverage the idea of Union types which is one of the most powerful thing that TS has but this idea is not well understood by OOP devs but by FPers mostly
May I add decorators to the list.
number size = 3.04
^^^ Breaking change
letby default,constif specified asconst number myVariable
^^^ Breaking change again.
Have you considered var & how JavaScript label is used ?
- Locally fork
@typespackage
I'm not sure if this was mentioned before (the thread is pretty long already) but I would like to finally see higher-kinded generics in TypeScript, yay #1213!!
Hi.
Is there some working repo with new handbook?
2 June today (last month of the roadmap), any news about new handbook?
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 provides).
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
More performant analysis infrastructure: The ESLint API allows for more efficient implementations of certain classes of checks. Although it would be possible to refactor TSLint’s APIs, it seems prudent to leverage ESLint’s architecture and focus our development resources elsewhere.
but the subtext is that Palantir’s team disagrees with Microsoft’s assessment about the architecture and that the main reasons for choosing ESLint are 1. it makes typescript more accessible for current javascript developers and 2. it reduces fragmentation in the typescript ecosystem.
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.
Really nice explanation @DanielRosenwasser - thanks for sharing! ❤️
Sidebar: I'd lay good money that comment 👆 was a reply to an notification email from GitHub that you wrote on a phone 😉