3 ms·
I could not disagree more. I absolutely love using TypeScript for the libraries that I write and maintain. > There's great documentation and blogs for end-deve
by mcluck 4y ago
I could not disagree more. I absolutely love using TypeScript for the libraries that I write and maintain.
> There's great documentation and blogs for end-developers but there's very little for library-developers
Because there isn't a difference. I write my applications the same way that I write libraries. TypeScript gives you the flexibility to do that as well. If you want to use looser types in your apps and in your libraries, go right ahead. Some people may want more accurate types coming from your library. They'll either improve them or pick something else. You aren't required to appease them. I know that you stated that you reject this notion but just now I was working on a relatively straightforward React app and I've got a number of places where I'm doing slightly more advanced types. If you aren't, you're probably leaning on library developers to do that for you which is fine but that's a choice.
> How do library developers debug their highly dynamic and heavy use of conditional types, overloads?
I literally just make a number of assignments and hover over the types to verify that they look right. There are better ways of testing these that I'll get to later.
// Hovering over this will either show what I want or not
type ComplexFoo = ToComplexType<Foo>
Sometimes those types might look nasty and be difficult to parse so there are ways to force TS to simplify them for inspection. There are even libraries[1] that help with that.
> I spend a decent amount of time in the redux world so redux-toolkit is a great library to see how types are done
Redux is an inherently very dynamic system. It's dynamic by design. Capturing all of that dynamism in a strict system is _hard._ `redux-toolkit` and related codebases are not representative of the normal struggles for library developers. Additionally, see point 1 about how you can choose how good your types are. It would be technically correct for `createAction` to just return
interface Action {
type: string
payload: unknown
}
They choose to make their types better so that developers don't have to carry that burden.
> It's pretty common in style guides to never nest ternaries. In typescript, that's the only way to narrow types based on other types
I'm always open to syntactic improvements. If someone finds a way to make the type syntax simpler without conflicting with existing JS syntax then I will be very happy. That being said, the syntax isn't so inscrutable as to be unusable. It just takes some getting used to.
> It's not enough to test your types against the latest version of the typescript compiler either, you also need to test against previous versions
I disagree. The TypeScript team does a very good job of keeping things backwards compatible. In the rare case that they don't, your library is welcome to state that they only support certain versions of TypeScript. This is a pretty standard problem with any sort of dependency. Nothing about TypeScript makes this particularly difficult. If you are going the extra mile to check multiple versions of TypeScript then you're awesome.
> This new class of tests are in their infancy and there's a baron wasteland of tools that are now deprecated or partially maintained
My opinion: a lot of these tools become unmaintained because they aren't necessary. Testing types is pretty easy. Include these two functions and you're golden.
function generateType<TReturn>(): TReturn {
return null as unknown as TReturn
}
function assertType<TExpected>(value: TExpected) {}
Then testing your types is as simple as
assertType<Expected>(generateType<ComplexThing<number>>)
> When first attempting to contribute to a project, one must grok the application logic as well as the type logic.
If you're running in to this then those people are doing it wrong. Types should make impossible states impossible and do their best to make the application logic the only thing that is possible. If you understand the application logic, you understand the type logic. They're one and the same.
> I shouldn't have to read the typescript compiler source code in order to figure out why it's resolving a piece of my code to a specific type.
You shouldn't and you don't. Better documentation is always better though and I agree that more in-depth first-party documentation would be great.
[1]: https://millsp.github.io/ts-toolbelt/modules/any_compute.html https://millsp.github.io/ts-toolbelt/modules/any_compute.htm...