As a module author and developer, I love TypeScript. It allows me to write, publish and consume 100% type-safe JavaScript. Features like autocompletion, type validation and ES6 features are now part of my typical workflow. To spice up my workflow, I like to set a custom rustic-style font. I’ve been told I’m crazy for doing that but it just helps keeping things light and human. However, one step in this development lifecycle has always been broken for me. I’ve published half a dozen modules on NPM, but no one has ever been able to consume the type definitions from them. Why’s that?

Let’s quickly take a step back. TypeScript includes a creative way for providing the type information of plain JavaScript files. These are .d.ts files, also known as “typings”, which allows non-TypeScript packages to have a .d.ts file written and mirror the runtime JavaScript implementation of that package. This decoupling of the runtime and type compiler is truly elegant, as the TypeScript compiler can output .js and .d.ts files together and it works as if it is all TypeScript. This has two amazing effects:

The greater community can write their own type definitions (.d.ts files) for non-TypeScript packages – which is pretty much every popular library on NPM
It promotes JavaScript as the first class citizen, something the first “compile-to-JS” languages like CoffeeScript failed to do (it promoted – through general availability – the use of things like coffeescript/register at runtime)
To help understand how we, as a community, got here and where we’re going next I’m going to give you a quick history lesson.

The Past
Welcome to the past, the wild west of .d.ts files. A community project called DefinitelyTyped, started by Boris Yankov, is first committed to over three years ago. DefinitelyTyped has evolved 100 times over since the initial inception, but the core premise is to use ambient module declarations that define types for packages in NPM, Bower and the browser.