Summarizing, I'm totally on board with using TypeScript as an app dev, which also means I want the libraries I use to be well-typed. As a lib maintainer, dealing with type definitions can be painful, but necessary.
Ultimately, the key for using TS in an app is to be pragmatic about type usage, and be willing to accept an 80% solution rather than obsessing over 100% "perfect" type coverage.
Thanks for linking your article. That's been almost exactly my experience right down to the details of dealing with PRs and the fanaticism with typing. I think it is too easy to equate TypeScript with 100% perfect types and perhaps that is what I have the bigger issue with. I just was trying to push the boundaries with my library especially in the area of JSX and TypeScript really felt like a limitation to creativity. Which has been hard simply because it's taken creativity to prove that a precompiled Reactive library can use JSX with so many recognizable naysayers like Rich Harris, and Evan You.
I do get why better typeable APIs generally are better and I've seen the same move to simple APIs after. But definitely painful when trying to push boundaries.
In any case great article and I've distributed it to my team.
Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
Instead, I JSDoc comment/type all public APIs and generate the typings as a pre-publish step. It provides all the benefits of TS (ie Intellisense + inline docs + type checking) w/ none of the downsides.
IMO, typing private/internal API surfaces is a waste of time. Tests should cover logic and a good linter should cover the rest.
The main reason I use this approach is it drastically lowers the barrier-of-entry for users/contributors.
TS really does add a ton of cognitive overhead. There's no one true/correct way to type code. This leaves room for ambiguity, which leads to friction diring review. In short, who the hell wants to waste time arguing over the 'correct' way to define types?
This is less of an issue on an internal team b/c everybody should be familiar with each other's individual styles.
On OSS projects where cohesion is generally low-to-non-existent, anything that introduces friction is a no-go.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wrote an extended post recently on my experience learning and using TypeScript as both an app developer and a Redux library maintainer.
Summarizing, I'm totally on board with using TypeScript as an app dev, which also means I want the libraries I use to be well-typed. As a lib maintainer, dealing with type definitions can be painful, but necessary.
Ultimately, the key for using TS in an app is to be pragmatic about type usage, and be willing to accept an 80% solution rather than obsessing over 100% "perfect" type coverage.
Thanks for linking your article. That's been almost exactly my experience right down to the details of dealing with PRs and the fanaticism with typing. I think it is too easy to equate TypeScript with 100% perfect types and perhaps that is what I have the bigger issue with. I just was trying to push the boundaries with my library especially in the area of JSX and TypeScript really felt like a limitation to creativity. Which has been hard simply because it's taken creativity to prove that a precompiled Reactive library can use JSX with so many recognizable naysayers like Rich Harris, and Evan You.
I do get why better typeable APIs generally are better and I've seen the same move to simple APIs after. But definitely painful when trying to push boundaries.
In any case great article and I've distributed it to my team.
As another lib dev I prefer not to use TS
Instead, I JSDoc comment/type all public APIs and generate the typings as a pre-publish step. It provides all the benefits of TS (ie Intellisense + inline docs + type checking) w/ none of the downsides.
IMO, typing private/internal API surfaces is a waste of time. Tests should cover logic and a good linter should cover the rest.
The main reason I use this approach is it drastically lowers the barrier-of-entry for users/contributors.
TS really does add a ton of cognitive overhead. There's no one true/correct way to type code. This leaves room for ambiguity, which leads to friction diring review. In short, who the hell wants to waste time arguing over the 'correct' way to define types?
This is less of an issue on an internal team b/c everybody should be familiar with each other's individual styles.
On OSS projects where cohesion is generally low-to-non-existent, anything that introduces friction is a no-go.