3 ms·

JavaScript itself keeps changing, so we need to keep pace with that, for one. Beyond that, we relentlessly seek to improve how people interact with our editor t

JavaScript itself keeps changing, so we need to keep pace with that, for one. Beyond that, we relentlessly seek to improve how people interact with our editor tools, and make additions to the (type) language and compiler to support that. .d.ts files from js files, for example, are highly motivated by a desire to better support incremental compilations with .js inputs, as .d.ts files are used as incremental metadata. Assertion signatures were added to better express the cross-call control flow patterns some (assertion) libraries already use, to make using them in a well-typed way more ergonomic. Generally speaking, it's not often we add something that _invalidates_ the old way to do something (in the language) - our additions are usually made to make new patterns possible to express.

vosper 7y ago
Thanks for the response. I do appreciate the efforts of the team, and am planning to continue learning TypeScript :) Maybe this exists, but one thing that would be super helpful is a document that explains any places where there's a "new best way" of doing things, and also details what the old way was. Here's an example from yesterday: I was Googling about extending a type (I think) and the first SO result (top of Google) says "you can't do that in TypeScript"... but reading the comments someone had said "actually you can, in 2.6 or later". That's the kind of thing that it would be great to have summarised in one place. Not necessarily all the changes (ie, not just all the release notes) but specifically where the language has changed and an old way of doing things, or a previous restriction, is gone. Preferably with examples. (I'd try to create this, but I don't have the skills to do so).
- wwwigham 7y ago
  We actually primarily use StackOverflow for this (as it's the first resource many devs go to, as you did, and it's collaborative). We even pre-seed questions and answers for releases, sometimes. If you find an answer on SO is out of date - suggest a new answer (or ask for one) and get it updated (there's far, far too many for us to keep explicit track of them, there's only a handful of us on the team)! :D

vosper 7y ago

Thanks for the response. I do appreciate the efforts of the team, and am planning to continue learning TypeScript :) Maybe this exists, but one thing that would be super helpful is a document that explains any places where there's a "new best way" of doing things, and also details what the old way was. Here's an example from yesterday: I was Googling about extending a type (I think) and the first SO result (top of Google) says "you can't do that in TypeScript"... but reading the comments someone had said "actually you can, in 2.6 or later". That's the kind of thing that it would be great to have summarised in one place. Not necessarily all the changes (ie, not just all the release notes) but specifically where the language has changed and an old way of doing things, or a previous restriction, is gone. Preferably with examples. (I'd try to create this, but I don't have the skills to do so).

wwwigham 7y ago
We actually primarily use StackOverflow for this (as it's the first resource many devs go to, as you did, and it's collaborative). We even pre-seed questions and answers for releases, sometimes. If you find an answer on SO is out of date - suggest a new answer (or ask for one) and get it updated (there's far, far too many for us to keep explicit track of them, there's only a handful of us on the team)! :D