4,032 karma · joined January 16, 2015
@drosenwasser on Twitter.
DanielRosenwasser on GitHub.
Who would do that apart from existing type-checkers? A team like TypeScript, that's who. :)
> Noticing the time when you posted your comment
Uh, I am just kind of a night owl. Most of our team members work out of Redmond, WA, and our distributed members are either on the East or West coast of the US.
If you've got examples of cases where we can do better, feel free to file an issue! We want to do better.
We're considering ways we can avoid a full type check: https://github.com/microsoft/TypeScript/issues/31417
In the meantime, you can try out turning on the `skipLibCheck` compiler option to see if that helps at all, but be warned that it might not catch conflicts across multiple files.
Then create a `types.ts` file for types that are used throughout your project, and as you see common data structures being used in your program, declare `interface`s and `type` aliases there. Then you can switch your `.js` files to `.ts`/`.tsx` files one-by-one and add types (or even add types via JSDoc and then convert those to `.ts` files when you're ready).
Eventually for the best experience, you can start switching on strictness modes. `strictNullChecks` is a pretty great one to use early on. Then `noImplicitAny` and `noImplicitThis` when you have pretty good type coverage. Finally you can turn on the full `strict` flag which will turn the others on, which are pretty easy to integrate into your codebase (and which you can turn off individually).
In fact, we're very mindful about the cognitive overhead of new features, but we're also motivated by pragmatism. These features have been highly demanded to help them write real-world code. My coworker Ryan has written up a pretty good explanation of why we tackled the feature set that we did: https://news.ycombinator.com/item?id=16277367
Keep in mind that TypeScript strives to model JavaScript as it's written broadly. While we could always take the stance that you have to rethink the way you write JavaScript, that would be unnecessarily stubborn. Hope that gives some insight!
I'll also note that incredible folks like James Henry have already written tools to convert TypeScript ASTs to the ESTree format[1]. I've heard it's been working well for using ESLint on TypeScript code.
Type 'Boolean' is not assignable to type 'boolean'.
'boolean' is a primitive, but 'Boolean' is a wrapper object. Prefer using 'boolean' when possible.TypeScript tries not to impose any sort of restrictions on coding style.
That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error.
With async/await, we had to rewrite our emit pipeline, which meant that we needed to keep parity in both output as well as time to emit. The investment has shown, and TypeScript is still extremely fast.
We're always willing to think about different approaches, but those are some of the rationales here.
If you're referring to differences in the way TypeScript narrow types based on control flow analysis, we don't see one as being "better" than the other, but TypeScript takes a more optimistic approach to avoid putting users in frustrating scenarios where the analysis is too limited. Most users tend to prefer this to the slightly more rigid approach used in Flow, so we felt we made an ideal choice there.
If you have any specific thoughts or ideas, feel free to leave us feedback on our issue tracker.