[qudat]

Thanks for reading the article!

> That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API.

I think that's a fair point, but generating types that satisfy all use cases is very challenging to get right -- disproportionately so. I could see a world where -- without proper tooling and growing complexity -- typescript libraries becomes so difficult to maintain that people give up or burn out. Maybe that's a pessimistic outlook but I already feel that way some days.

[Chabsff]

In strongly-typed programming languages, which includes Typescript, figuring out the types *of the interface* is not something that's done after the fact. `@types/*` is an exceptional project meant to back-port JS libraries to TypeScript, but that's the exception, not the rule.

If you write a library in TypeScript, determining what types are present as part of the interface is one of the very first thing that should be done.

[mrkeen]

> In strongly-typed programming languages, which includes Typescript, figuring out the types is not something that's done after the fact.

Too broad a statement. There's loads of value in having a compiler figure out types for you after/when you write the code.

[Chabsff]

Hard disagree as far as the portions of it that are part of the user-facing public interface are concerned.

But granted, as a general rule you are correct. I was referring specifically to API interfaces.

[overgard]

If you're talking about type-inference, sure, I guess it's fine.

If you're talking about figuring out what types you're going to accept, you should absolutely be defining that on your own up-front. If you don't even know what your types are how is an end user going to figure it out?