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.
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.