5 ms·
I'm not sure I understand what you mean by "the client loses most the advantages of your library being in TypeScript in the first place." Your library still exp
by danielmason 11y ago
I'm not sure I understand what you mean by "the client loses most the advantages of your library being in TypeScript in the first place." Your library still exposes a more clearly-defined API by making types explicit. And saying that the downstream consumer doesn't get the benefit of compile-time type checking if they've chosen not to use type checking is...kind of a truism?
- robert_tweed 11y agoThe problem is with the author's assertion that all libraries should be using TypeScript and not, say, Flow, or some other alternative that achieves the same goals, perhaps better.
- MadcapJake 11y agoDoes Flow offer type definition files?
- AgentME 11y agoYes. Also, there isn't a need to maintain a separate definitions file[1] if the library was developed as Flow-typed code. I've made a few small libraries[2] that were written with Flow-typed code, and are built so that the types are automatically enforced if you use the library in a Flow-typed project. [1] A hand-maintained definitions file: https://github.com/facebook/immutable-js/blob/master/type-definitions/Immutable.d.ts https://github.com/facebook/immutable-js/blob/master/type-de... . Sure, it's nice as documentation, but that is a lot of redundant effort if you already have separate documentation, and types and documentation in the original source code too. [2] https://github.com/AgentME/contain-by-screen https://github.com/AgentME/contain-by-screen is one simple example.