Hacker News Reader

Comment by jstclair | Hacker News Reader

Sure, but that's a bit of a burden for library authors, don't you think? I appreciate all the freaking hard work the definitely typed guys do, but I hunk there's a few structural problems in the project:

  * everything in a single repository on GitHub. Makes it hard, for instance, to reuse from other package managers, like Bower
  * they don't have a good story around versioning different libraries. Last I checked, they had a typescript wrapper for jQuery, based on the latest version. Sticking with an older version? No accurate type definitions for you!

View on HN

> they don't have a good story around versioning different libraries. Last I checked, they had a typescript wrapper for jQuery, based on the latest version. Sticking with an older version? No accurate type definitions for you!

Nobody forces you to stay up-to-date with the DefinitelyTyped repository. If you want definitions for version X, look at the definitions that were recent shortly after version X was released. Not completely effortless, but also not a structural, deal-breaking problem like you said.

Well sure but compare that workflow with almost any other package manager. NuGet, for instance:

install-package jQuery --version 2.0

We haven't had major problems with DT, but I see that over time this is crying out for a fix

It's not just about staying at a particular version. It is about being able to find the version that matches what you are using. I recently started an new project using bootstrap and had to downgrade to v3.0.3 due to some incompatibilities. I have no idea how I would go about finding the matching type definitions from definitely typed. Their version numbers don't match bootstrap's (http://www.nuget.org/packages/bootstrap.TypeScript.Definitel...).

Also, how will the Definitely Type project be able to handle a fix to the definitions of an old version that doesn't apply to the current version?

Like jstclair I appreciate their hard work, but I think they really need to change their approach soon to avoid a lot of pain down the road.

There is a project that converts Typescript to Closure type annotations. If you do this, and put Closure Compiler in your continuous build/test phase, it will can catch when there is a mismatch between the caller and the library, not in all cases, but it helps.

I wasn't talking about manually adding in the assertions into the library code. The idea is that you would take the type declarations that people are already writing and have the Typescript runtime add some sanity checks to verify that they are correct. TS doesnt do that because it insist on not including any extra runtime code so if there is a error in a type declaration that problem might go undetected or onyly cause an exception in a different part of the code.

I can see that library versioning would be annoying but I think its more of a ecossystem problem then a technical one.

I'm DT org member: I posted a big reply about DT further in the thread: https://news.ycombinator.com/item?id=7498775

Reply on news.ycombinator.com