
The Future of TypeScript Declaration Files - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/
======
drinchev
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...](https://github.com/typings/typings/issues/223#issuecomment-204802254)

2 :
[https://github.com/shyiko/tsdm/issues/4](https://github.com/shyiko/tsdm/issues/4)

3 :
[https://github.com/DefinitelyTyped/DefinitelyTyped/issues/21...](https://github.com/DefinitelyTyped/DefinitelyTyped/issues/2150#issuecomment-117705706)
( July 2015 )

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

~~~
DanRosenwasser
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.

------
dvdcxn
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.

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

~~~
bcherny
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.

~~~
drinchev
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.

~~~
pyrophane
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.

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

------
dumbmatter
How do people using Flow handle this problem?

~~~
lbljeffmo
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/](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.

------
JoshGlazebrook
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.

------
Rapzid
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!"..

------
cpprototypes
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).

~~~
wereHamster
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).

~~~
DanRosenwasser
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](https://github.com/Microsoft/TypeScript/pull/9163)

------
nojvek
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.

------
k__
didnt they just consolidate everything to typings?

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

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

~~~
DanRosenwasser
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.

~~~
k__
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 :)

~~~
DanRosenwasser
None taken! It's totally a valid question.

