Function declarations Destructuring also works in function declarations. For simple cases this is straightforward: type C = {a: string, b?: number} function f({a, b}: C): void { // ... } But specifying defaults is more common for parameters, and getting defaults right with destructuring can be tricky. First of all, you need to remember to put the type before the default value. function f({a, b} = {a: "", b: 0}): void { // ... } f(); // ok, default to {a: "", b: 0} Then, you need to rememb

Overloads and Callbacks Don’t write separate overloads that differ only on callback arity: /* WRONG */ declare function beforeAll(action: () => void, timeout?: number): void; declare function beforeAll(action: (done: DoneFn) => void, timeout?: number): void; Do write a single overload using the maximum arity: /* OK */ declare function beforeAll(action: (done: DoneFn) => void, timeout?: number): void; Why: It’s always legal for a callback to disregard a parameter, so there’s no need f

Publish to npm The Publishing section explains how to publish your declaration files to an npm package, and shows how to manage your dependent packages.

Merging Namespaces with Classes This gives the user a way of describing inner classes. class Album { label: Album.AlbumLabel; } namespace Album { export class AlbumLabel { } } The visibility rules for merged members is the same as described in the ‘Merging Namespaces’ section, so we must export the AlbumLabel class for the merged class to see it. The end result is a class managed inside of another class. You can also use namespaces to add more static members to an existing class. In additi

Boolean The most basic datatype is the simple true/false value, which JavaScript and TypeScript call a boolean value. let isDone: boolean = false;

Using Modules Just like namespaces, modules can contain both code and declarations. The main difference is that modules declare their dependencies. Modules also have a dependency on a module loader (such as CommonJs/Require.js). For a small JS application this might not be optimal, but for larger applications, the cost comes with long term modularity and maintainability benefits. Modules provide for better code reuse, stronger isolation and better tooling support for bundling. It is also worth

Optional Properties Not all properties of an interface may be required. Some exist under certain conditions or may not be there at all. These optional properties are popular when creating patterns like “option bags” where you pass an object to a function that only has a couple of properties filled in. Here’s an example of this pattern: interface SquareConfig { color?: string; width?: number; } function createSquare(config: SquareConfig): {color: string; area: number} { let newSquare = {c

TypeScriptCompileBlocked If you are using a different build tool to build your project (e.g. gulp, grunt , etc.) and VS for the development and debugging experience, set <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> in your project. This should give you all the editing support, but not the build when you hit F5.

Needless Namespacing If you’re converting a program from namespaces to modules, it can be easy to end up with a file that looks like this: shapes.ts export namespace Shapes { export class Triangle { /* ... */ } export class Square { /* ... */ } } The top-level module here Shapes wraps up Triangle and Square for no reason. This is confusing and annoying for consumers of your module: shapeConsumer.ts import * as shapes from "./shapes"; let t = new shapes.Shapes.Triangle(); // shapes.Sha

Publicize your declaration file After publishing your declaration file with your package, make sure to add a reference to it in the DefinitelyTyped repo external package list. Adding this will allow search tools to know that your package provides its own declarations.