You basically can't implement iterators while using `strictNullChecks`, and it's been broken since at least October 2016 (!)
Every time I go to use TS for a personal project I check to see if this is fixed, and for almost two years the answer is no. I am dying here. Should I not be implementing iterators? Does no one use `strictNullChecks`?
Looks like whenever 3.0 is released.
We expect contributions from everyone thats the motive behind OpenSource And not just being transparent of code
Has anyone had a truly pleasant experience with Typescript in a medium to large project?
Tried twice to wrap my head around what you are even talking about.
TypeScript is totally wonderful. It's also optionally typed.
I use it on a non trivial project with multiple teams.
Was introduced to it last year and it's fantastic compared to plain js.
This was generated by one line of code, simply applying the hoist-non-react-statics library as recommended by the official React docs https://reactjs.org/docs/higher-order-components.html#static...
JavaScript in many cases can be too dynamic to be properly typed. I'd rather have it than not - it has saved my ass a good number of times - but let's not pretend TS/Flow is totally wonderful.
On the other hand, when writing server code targeting Node, with lots of dependencies on micro-libs, I've definitely had the experience of struggling with outdated or incorrect type definitions.
However, nowadays TypeScript has much better interoperability with untyped JS code. You can generally import an untyped JS module with the minimum of ceremony and have it Just Work (the type will be "any", so you don't get intellisense).
I find the best approach is to import types for the big libs you are using, like Express, and leave the micro-libs untyped. That way you get the benefit of types on your own code and your interactions with the framework, but can still leverage other code when you need to without giving yourself a headache.
Using yarn.lock means it never breaks unless we specifically choose to upgrade though, so it's still worth the increased productivity and safeness from TypeScript, which is awesome as a language especially combined with VS Code.
DT packages almost need _two_ version numbers that npm checks for semver breaks, but how to make that work is an open question and an interesting edge case in package management.
(I got some hate for one of my refactors, that I needed to get my own code to type correctly, that touched quite a few DT packages in the "middle" of an upstream major version, so I know this pain quite directly from both sides.)
It's not perfect, but we have found the types to be very nice when working on a large code base with lots of people. Dev development cycle remains quite fast.
In the worst case scenario, revert to local (checked-in) type definitions and fix it.
It never was a problem for me after more than 5 big TS projects.
They have added a ton of language features and keep adding more with each release, lets hope it doesn't get bloated as scala.
For me it feels not as bloated as other languages which added features without thinking about how they fit to the existing ones. But I work a lot on Scala, so I'm probably biased since I know the language better than i.e. Typescript :)
a) The lack of a proper 'is' keyword. The current behaviour around this is mental.
b) The unneeded complexity that the recent releases have brought to the typing system.
That post outlines a few use cases which are admittedly outside of everyday JS/TS usage but I can see them as quite powerful when, for example, building frameworks and libraries that expose an API. I'd offer real-world examples of my own but I'm still working it out for myself .)
A lot of this matters in "metaprogramming" like Readonly<T> and Partial<T> which use all of the existing keys in a type to produce a "new" result (none of the key can be set, and all of the keys are optional, respectively), and making sure it doesn't miss intentional keys like symbols and numbers.
For good measure I recently wrote a blog post on writing your first TypeScript+React application: https://charmeleon.github.io/post/react-typescript-tic-tac-t...
I'm so grateful for TypeScript, it's the hero JavaScript desperately needed.
type TemplateTypedSelect = new () => Select<Template>;
const TemplateTypedSelect = Select as TemplateTypedSelect;
return <TemplateTypedSelect {...props} />;
Our codebase was sprinkled with these, which was both silly and error-prone. This will be a huge quality-of-life improvement, and encourage people to create type-safe React components that ensure a match between their inputs and callbacks, rather than just having them put a union of all the types they can handle in both.