Great News! I was bragging about this everywhere on GitHub [1], [2], [3].

There is a huge problem for me for the last couple of months that will end with TypeScript 2.0, which is >Where should one publish, contribute typescript definition files and how?<.

I'm really happy that TypeScript's team decided to go NPM-only on that.

1 : https://github.com/typings/typings/issues/223#issuecomment-2...

2 : https://github.com/shyiko/tsdm/issues/4

3 : https://github.com/DefinitelyTyped/DefinitelyTyped/issues/21... ( July 2015 )

This isnt' a nitpick but a genuine question because I am unsure: Should that be --save-dev rather than --save, given that typings are very much a dev/compile/transpile time concern rather than runtime concern, or is there a reason for using --save?

If you're a library author, then our feeling is you want to use `--save` because that saves your consumers the need to install the declaration files themselves.

If you're writing a project that won't be consumed by anyone as a library (e.g. command line tool), it makes sense to make that devDependency.

I have some additional genuine questions:

* How would scoped modules' (@scope/name) typings be named in this convention?

* How do the version of these new typings modules correlate to versions of the underlying modules? In other words, how can I access the typings for the previous major of lodash from which breaking changes emerged?

The major and minor version of the types modules corresponds to the version of the underlying package; the patch version will increment when the type definition changes.

We're still figuring out what to do with scoped packages in this scheme. Most likely we'll end up with a single types package for everything under a specific scope, since that's what people seem to be using scoped packages for. They're pretty rare so far so this is kind of TBD.

For clarity, can you give an example of how to `npm install` an old version of lodash such that we get the old version of the lodash.d.ts?

Assuming it was published, `npm install @types/lodash@2.0.1`.

Only slightly related this, but does anyone else have an as intense dislike of definitely typed as me? I much prefer typing's registry based approach and I'm surprised Microsoft is running with definitelyTyped instead.

>Sorry, we had to truncate this directory to 1,000 files. 823 entries were omitted from the list.

Shudder.

And if the package supports the "typings" property, you don't even need to separately install types.

In my year or so of using TS, I've noticed that this is the only sort of typing that doesn't get out of date, and is high quality. Even something as popular as lodash typings lag behind the newest lodash releases, are missing typings, and have many poorly written types.

I guess until typings are more broadly adopted and are shipped with most popular repos by default, this is the best we can do.

I doubt that typings will be shipped with most popular repos. I actually think, this is a dream that will never happen.

What I think TS team did and I'm so happy about it is that they made the easiest possible way for us TS devs to contribute to the definition files in a distributed way.

Agreed. Unless everyone starts developing in TypeScript then external types for JS files is always going to be a bit of pain and not quite where we'd like it to be.

Or if the TS declaration file format gets widespread adoption among flow, babel, ECMAScript etc.

How do people using Flow handle this problem?

In the past 2-3 months, various members of the Flow community and I have been working together on flow-typed (https://github.com/flowtype/flow-typed/) which is a centralized repository of library definitions.

One bit of feedback we received from many DefinitelyTyped users was that it provides a large repository of definitions to get started, but often the definitions are out of date, un-versioned, not well-tested, use lots of `any`s, etc. What we took away from this was that whatever we do, it needs to have a focus on quality and really leverage the community. It should be as simple as possible for anyone to contribute improvements to libdefs, but also we want to make sure those tweaks and improvements are verified by both people AND automation as much as possible.

We looked at the approach of using npm to define/distribute library definitions, but we decided to go with something more integrated instead for consistent coordination/testing/versioning/tooling/validation/etc.

For example: We use automated CI to ensure that all libdefs are tested and versioned against both the library and the version(s) of Flow they are meant to work with. Additionally, we intend to continue building more ways to automatically verify libdefs. Things like heuristics to detect when an impl doesn't align with interface, well-typed tests to allow community members to do this verification themselves, bots that can offer suggestions on pull requests when they see types that could be better written in a different way -- things like using `any` vs `mixed`, etc.

Also, if a new version of Flow goes out with features that might make a libdef better/more expressive, anyone in the community can contribute an update with the same level of assurances without worrying too much about breaking users who use an older/different version of Flow.

Another thing we want to do is to make sure that packages that use Flow in the first place never have to write implementation/interfaces separately, but are still able to easily publish them separately.

For this, we've started encouraging libraries to publish with a .js.flow "shadow" file alongside their compiled files. In the future, flow-typed will be able to automatically extract a library definition from these shadow files that is versioned against both npm and the version of Flow the library was written with. From there, the community can help maintain that auto-generated type interface for newer/older versions of Flow, etc.

This was definitely needed. There has been so much change in regards to type declaration and where to get them (DefinatelyTyped, tsd, typings). I also look forward to the documentation on creating type declaration files as it's all over the place right now. The whole namespace/internal module/external module confusion doesn't help either.

Is it going to become easier to contribute? I run into problems occasionally and have zero clue how to contribute improvements back.

I really hope this will be less confusing than typings.. All the sources, ambient(global) vs not, etc. Currently I just read the error and do what it tells me. Why that extra step is necessary is beyond me; "Broken, click to fix!"..

Does anyone know if the ECMAScript group is seriously considering adding something like TS? Maybe in ES8 or ES9? TS 2 will be impressive and it seems TS has a lot of momentum (such as Angular 2).

Brendan Eich made the following comment here a while back but I don't know if what he hoped for had made any progress:

" Indeed we had structural types in ES4 toward the end, and almost bluffed MS into folding (I'm told by a reliable source). But ES4 was trying for too much too soon. At this point we really need to see ES6/7 and TypeScript + Flow "gene- culture co-evolution". As I said at the last TC39 meeting on the topic, big de-facto standard wins trump rushed de-jure standards any day. /be"

and also:

" Type system implementors and the JS stewards must communicate well for this to win. It's looking good so far, on Ecma TC39: JQuery, Facebook, Netflix, PayPal (Ebay originally, and again), Twitter all represented along with Apple, Google, Microsoft, and Mozilla. Also academic researchers from various universities, all of whom love type systems and theory :-)."

https://news.ycombinator.com/item?id=8906807

Would be nice, but I think we can do much better than what TS gives us right now, on the level of the type system. What's really missing are ADTs / sum types (and pattern matching, though that is more an implementation detail).

I agree, ADTs would be nice. In fact, we have a pull request out for it right now. [1] :)

[1]: https://github.com/Microsoft/TypeScript/pull/9163

Speaking of Angular 2, will we have to wait until Angular v3 for it to use TypeScript v2?

I wonder if there is a way for automatic Jsdoc to ts interfaces generation. In that way a lot of libraries can always keep the .d.ts in sync or rather users can just generate from the module.

didnt they just consolidate everything to typings?

While I totally think typescript is great and getting better all time the same thing just came to my mind. I started a typescript project end of last year and since then I have already moved from tsd to typings to a new incompatible typings version. Seems to be not the end of the journey.

Who's "they"? typings is a third-party tool not developed by the TypeScript team.

yes. but it was used in tutorials by MS so it seemed like a de facto thing...

To clarify what Ryan's getting at, the TypeScript community has started moving to Typings, but there were still issues and pain points that we needed to address to avoid common problems.

While we did write tutorials using Typings, that content will change to use npm by our next release. Our guides are pragmatic, and are meant to get you working with TypeScript today. Making users use nightly releases would've been a major pain.

No offense.

I just started using typescript and the the tuts already weren't up to date, which let me believe typings is the "new" way.

I met the pains you talk about and think npm is the right way :)

None taken! It's totally a valid question.