The Future of TypeScript Declaration Files

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.

* 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?

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

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.

" 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